Dear Maintainer,

My system was set up years ago, with a root partition that
is not really big enough anymore. Repeatedly, when I run
updates, I get in trouble because space on the root partition
runs out.

However, with most packages, this just means that setup fails,
and after I make some room, a "dpkg --configure -a" sets things
straight.

redis-server, not so. The script gets stuck, not erroring out and
not finishing. Even after it is killed and room becomes available,
it's still a hard fight to get it to complete; sometimes an
uninstall+install is enough, today, not even that seems to work.

BTW, when I say "killed", I do mean killed: Ctrl-C does nothing to
the dpkg or aptitude process. It needs to be stopped with ctrl-Z,
and then killed.

Hi Shai,

Hm. Do you know what part of the postinst script is sticking? You may
be able to find out by looking at your process table eg. via top or
htop.

(My initial guess is that redis process itself gets wedged when it has
no diskspace, and then—even after freeing some space—the postinst is
waiting for it to restart?)


Regards,

Hi Chris,

I think I saw something like that, indeed, one of my probes into the
system showed that a "systemctl stop redis" or something very similar
was still running.

This seems quite odd to me -- I thought Redis, at least in its default
configuration (which is what I use), was an in-memory database. Why
would it get stuck over low disk space? And, if it does get stuck --
why wouldn't we just kill it? And how come the postinst script is
SIGINT-resistant?

Hi Shai,

Well, when stopping or restarting, redis will persist the contents of
memory to disk.
memory are persisted or we will encounter data loss. (This is achieved
through TimeoutStopSec=0 in the systemd unit file.)

What is perhaps happening on your system is that Redis does not
realise that there is (now) more disk space available and it should
really try to continue. (What do the logs say? strace might be able to
tell you more as well.) In either case, this is almost certainly
something for the upstream developers to address.


Regards,