Package: molly-guard Version: 0.8.4 Dear Maintainer(s),
molly-guard currently works by diverting an arbitrary series of legacy executables to avoid accidental reboots. While this worked in ye olde times when executables where the only way to reboot a system, those days are long past. There are several programmatic IPC APIs to reboot a system nowadays, for example D-Bus via org.freedesktop.login1 and org.freedesktop.systemd1, and in the near future Varlink sockets too. There's also the systemctl executable. Fortunately nowadays there is a system-wide API to block/delay reboots, suspends, shutdowns and so on. It's the API that desktop systems such as GNOME already make use of. The inhibitors lock, described at: https://systemd.io/INHIBITOR_LOCKS/ In the past, this API was confusing, as in some cases inhibitors were implicitly and silently ignored (for example, when a request came from root). Since systemd v257 which is now in unstable and testing, this is no longer the case, and inhibitors are _always_ respected, unless an _explicit_ override is requested. So please consider switching molly-guard to use inhibitors to block/delay the shutdowns instead, so that all shutdown methods are covered, and fragile dpkg diverts are avoided. In general, we do not wish for files in the systemd packages to be diverted via dpkg. Holding a lock is very simple, and there's a command-line utility that implements the necessary code for scripts, so one can simply run something like: systemd-inhibit --what=shutdown --mode=block --who=molly-guard -- why="some user-friendly message" sleep infinity and for as long as the sleep runs, shutdowns will be blocked. It is of course fine to keep the old implementations when systemd is not running, but I would be extremely grateful if molly-guard stopped diverting binaries and used inhibitors when systemd is installed (for example, by having two packages with the appropriate conflicts - just an idea). Please let me know if you have any questions about the protocol. Thanks!
