On Fri, Jun 05, 2020 at 10:34:47AM +0200, Julian Andres Klode wrote: > On Fri, Jun 05, 2020 at 04:34:23AM +0300, Aleksey Tulinov wrote: > > systemd-inhibit --what="shutdown" --mode="block" /internal/path/to/dpkg $@ > > Let's try this again: We run dpkg multiple times. We need to run dpkg > up to a safe point where you can shutdown without ending with a broken > system you possibly can't recover from.
dpkg already does that. In fact, it uses really slow methods to increase chance of survival on ancient unsafe filesystems like ext2. If dpkg being interrupted leaves a system unrecoverable, that would be a severity:critical bug and a fat regression over what we enjoyed for decades. And that's for interrupting dpkg inside one invocation. Between invocations the committed state is even more consistent, and fsynced to the disk. > Stop telling us what to do, you don't have a clue. > > dpkg being invoked as a process is a hack, a workaround because dpkg's > library is unusable, it's not a design decision......................... > in fact ... it's a lot of issues. There are a lot of design breakages in dpkg, but this isn't one. I believe I did enough reinventing of dpkg to have a clue. > > and let it be something else in other distros? > > What are you on about now? Other distros can make their own choices, > and build apt without the systemd dependency. This is bug tracker for _Debian_ not Ubuntu. Ubuntu is systemd-only, Debian is not. > > And if you want something that works <quote> equally well <end quote> > > to systemd's inhibit, why not use systemd-inhibit in the first place? > > We are using the library that was designed for that purpose. You don't > call binaries you've got a library for. That would be a hack. Except that the library is fragile, thus shouldn't be used this way from a vital component of the system without being able to handle failures. Solutions include: * dlopen()ing the library * executing a binary -- of which, the latter provides more isolation thus is safer. > > This dbus voodoo looks a lot like a race condition to me anyway. If > > systemd-logind is going down before dpkg can send out dbus message, > > which probably can happen during shutdown, who's going to process this > > message and inhibit shutdown? `Inhibitor` doesn't do anything with > > returned `Fd` > > Don't talk about stuff you don't know anything about. It does not help > you. What we do with the fd is what we're supposed to do - keep it open > until we are done. Closing the fd is what releases the inhibitor. As long as dbus and logind survive. Try eg. crossgrading architectures to see them fail completely -- which is not a problem with other tools. > Right, let's just fail if we can't inhibit, because we don't support > non-systemd systems. Winner! That's Ubuntu, not Debian. The GR was clear -- option F which would have dropped support for non-systemd has been rejected. We ship multiple other rc systems: sysv-rc, openrc, runit, container-specific tools, etc. And we even financially sponsor development of non-systemd stuff. Systemd doesn't even _work_ on some popular containers, and it doesn't work either on some non-obscure setups (like, my personal workstation). This is fine with Debian; you as a core Ubuntu dev are biased towards it, but for me, Ubuntu being systemd-only is a hardship. As qemu fails to properly emulate hardware I work on, I need to use small dingy boxes instead of my fat one just to test if Ubuntu is ok. For this reason, validating $dayjob stuff on Ubuntu done by me is less adequate than it should be. > Sure, I mean we could check if we are actually running on systemd and > then log a warning, but then we also don't work with the libsystemd > shims if they gain support for this, so why bother? Why even a warning? All the inhibit thing does is to prevent the admin from doing something stupid (rebooting during an upgrade), and even that has non-fatal results. Debian had no inhibit at all for decades and the sky wasn't falling -- so it's a purely facultative option. If the system has been booted using systemd and systemd is in an usable state (no changing archs, etc) then inhibit will work -- otherwise, that particular handhold won't be there. > This is a best effort thing, there's nothing sensible we can do if it > fails, except for logging a warning, and that does not help a lot. We > don't want to issue an error obviously because you still want to be able > to upgrade the system if your dbus is down or stuff. Just silently ignore a failure to inhibit. > This bug is open to document our decision, not for people to harass > us. Maybe this was a bad idea and I should have closed and archived > it to avoid it attracting trolls. And hide problems, right? > I mean, I guess I could just create a filter and archive emails to > the bug automatically, but this still means everyone else gets > trolled. Would you accept a NMU fixing this, then? > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi ⠈⠳⣄⠀⠀⠀⠀
