On Mon, Sep 18, 2023 at 12:24:20PM +0200, Guillem Jover wrote: > While dpkg on systems using systemd _could_ by default take an > system inhibitor lock, and could provide a good enough reason like say > "Packaging system upgrade" or whatever, my concern has been with the > added dependency chain, and after reading your mail and thinking about > this now, I have to agree this seems like a higher level policy. > (Of course dpkg could also do that and grow a new --no-inhibit, > or --refuse-inhibit or similar option, but still.) > > But then, I recalled I had a git branch adding a dpkg-db-lock command > with a --wait-lock option, that I could recover and polish to provide > an example pre-hook script that would call that via a background > systemd-inhibit if systemd is running and the command is available, > where an admin that wanted to do that for their system or fleet of > systems could hook into the dpkg config. I've done that locally, and > will check whether that's viable and probably merge it for 1.22.1 > or 1.22.2, so that people that want to do it can easily do so.
I'm not sure how that works because you'd need to respawn yourself with systemd-inhibit, whereas the API essentially gives you a file descriptor over dbus that you keep open until it is safe to reboot. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en