Hi!

On Fri, 2021-07-16 at 15:23:01 -0400, Zack Weinberg wrote:
> Package: dpkg
> Version: 1.20.9
> Severity: normal
> File: /usr/sbin/dpkg-fsys-usrunmess
> X-Debbugs-Cc: za...@panix.com

> I tried to run dpkg-fsys-usrunmess from systemd’s emergency mode,
> thinking that this would be safer, since nothing else would be
> running.  This tickled a bug in systemd (see #991185) and got
> dpkg-fsys-usrunmess killed in the middle of its run—specifically,
> during the ‘dpkg --pending --configure’ operation.  As you can
> probably imagine, this is a really bad time for the process to be
> interrupted.
> 
> As a stopgap safety measure, I suggest that dpkg-fsys-usrunmess should
> use policy-rc.d to block all service activation while it’s running.

Hmm, right, that's not nice, sorry for the trouble. Hmm on one hand I
guess installing a policy-rc.d would make this safer, on the other, it
might end up not restarting services that will end up possibly using
old inodes or pathname references, which might affect service monitoring
for example, so I'm not sure what's worse.

But then I think the better option is to move the package
configuration at the end once everything has been unmessed and the
filesystem has been fully cleaned up. As «dpkg --pending --configure»
can always be issued at any later point, and should in theory be
easier to recover from. So I'm for now going to queue this one.

I'm also pondering whether any potential benefit from that step
(forcing reconfiguration of packages), to generate any potentially
missing files (which I'm not even sure it's an actual problem, but did
it out of defensive programming) is worth any potential problem this
might cause, like the one you just found. :/

Thanks,
Guillem

Reply via email to