On Tue, Mar 03, 2026 at 07:31:16PM +0100, David Kalnischkies wrote:
> [...]
>
> Am Tue, Mar 03, 2026 at 03:43:40PM +0100, schrieb [email protected]:
> > Maybe there is an explanation: users routinely launch dist-upgrades just
> > seconds before pulling the plug of their systems, when dpkg is in the
> > middle of a critical library upgrade; of course we need to protect them
> > with (1) and (2); moreover people so stupid are obviously not going to
> > benefit from the docs anyway, therefore also (3).
>
> Or, unattended-upgrade starts in the background.
Unattended-upgrade starts in the background? Then preventing
shutdown/sleep/hibernation is on u-a, not update-grub, ldconfig, sh,
debconf, dpkg, or apt.
> Or you have a laptop and
> more or less by reflex close the lid as someone comes by (which could very
> well cause not only suspend but hiberation) or or or.
And my browser should call dbus to inhibit hibernation whenever it
detects that I'm in the middle of a tax form submission; dpkg too
(because I might run directly "dpkg -iGROE /some/where" without apt's
supervision); ssh should inspect my traffic and detect when I'm performing
a system upgrade on a remote host?
> [...]
>
> Because that isn't the simplest solution. You have to identify what your
> problem is, find the relevant documentation, understand it, create
> a config file to disable this explicitly and maintain it for ever.
Or you notice this novel delay in apt, about half a minute, look at
the man page, find a note that describes precisely that syndrome
and suggests to add "-o DPkg::Inhibit-Shutdown=0" to the command line,
and be happy.
> Multiplied by every user that ever runs into this that isn't just
> throwing their hands in the air and gives up in frustration.
> Multiplied by every other tool that also interacts with login1 and
> hence runs into a related problem that you can workaround in some
> (other)way (hopefully).
I never had to install systemd-logind or elogind, until pcscd/trixie:
living without polkitd and org.freedesktop.login1 is definitely possible.
>
> The simplest solution is to find the cause of the problem (= why is dbus
> waiting needlessly for a timeout here?) and resolve it, so that nobody
> else runs into this (and related) problems ever again as it simple
> doesn't exist anymore.
>
> Yes, that involves work finding the cause, possibly coordination with
> other people and implementing and testing possible solutions, but
> it has no "by every user running into this" multiplier attached.
> Nor the "by every other tool" multiplier.
>
I still hope to convince you and Julian that the root of the problem
is not the behaviour of dbus or any other daemon, it's apt's dependence
on any daemon; that power management is not its job; that its job is to
drive dpkg, be it in single-user mode, without networking, with broken
/etc/fstab or /etc/crypttab. But I'm losing confidence.
> I was assuming you wanted to help in that process, but maybe I
> was wrong and you don't, which is fine, of course.
>
I _am_ willing to help, otherwise I wouldn't have exchanged that many messages.
>
> Also, Julian didn't say he won't document the option. But I don't
> consider that a good solution for this issue. You are welcome.
>
I agree, the best solution would be to disable that code path.
Best regards,
g
