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