> Sounds like a systemd bug - systemctl should have some way of handling
> a potentially non-responsive server
We have no way of telling the difference between a "non-responsive
server" and a Redis instance that is writing its state to disk. This
is how Redis shuts down by design.
This also appli
> Sounds like a systemd bug - systemctl should have some way of handling
> a potentially non-responsive server
We have no way of telling the difference between a "non-responsive
server" and a Redis instance that is writing its state to disk. This
is how Redis shuts down by design.
This also appli
On Wed, 2016-08-03 at 17:43 +0200, Chris Lamb wrote:
> Mark,
>
> Please retain CC's when replying, otherwise we lose history on the
> bug
> tracker.
>
> Please could you provide the output of:
>
> $ ps aux
>
> .. and also "strace -p" (as root) of the blocked process.
>
> >
> > Of course, rei
Mark,
Please retain CC's when replying, otherwise we lose history on the bug
tracker.
Please could you provide the output of:
$ ps aux
.. and also "strace -p" (as root) of the blocked process.
> Of course, reinstalling also resulted in the hang, so I'm just giving
> up on it, yanking it as no
tags 833189 + unreproducible
thanks
> Needed to use 'killall dpkg' from a separate terminal to
> recover
Unfortunately, I can't reproduce this:
$ wget
http://snapshot.debian.org/archive/debian/20160728T163948Z/pool/main/r/redis/redis-server_3.2.1-4_amd64.deb
$ wget
http://snapshot.debian.or
Package: redis-server
Version: 2:3.2.1-3
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation? Normal apt full-upgrade including some Sid
packages
* What exactly did you do (or not do) that was ef
6 matches
Mail list logo
