Bug#1129339: apt hangs for 25 seconds before acting if logind isn't running

On Tue, Mar 03, 2026 at 12:01:24PM +0100, David Kalnischkies wrote:
> Am Mon, Mar 02, 2026 at 11:52:34PM +0100, schrieb [email protected]:
> > No need to use a chroot.  Elogind ships its manifest
> > /usr/share/dbus-1/system-services/org.freedesktop.login1.service 
> > 
> >     [D-BUS Service]
> >     Name=org.freedesktop.login1
> >     # By default, Dbus activation of elogind is disabled. The daemon is started via an init script.
> >     # Exec=/usr/libexec/elogind --daemon
> >     Exec=/bin/true
> >     User=root
> > 
> > which
> > 
> > - advertises elogind
> > 
> > - prevents dbus from attempting to start the daemon (by design, because
> >   it lacks the necessary privileges)
> 
> But it is assuming that the daemon is running due to starting it via the
> init script by default, which you have disabled (or wouldn't happen in
> a chroot), I presume.
> 
> Instead of using `/bin/true` here it might be better to check if the
> daemon is actually running and fail if not. I assume that would tell
> dbus directly that the method isn't available rather than this pretend
> of it having successfully started and hence providing the method for use
> which `true` clearly does not.
> 
> Maybe something like:
> `Exec=/usr/sbin/invoke-rc.d --disclose-deny elogind status`
> works, but I haven't tested it, it is just a wild guess.
> 
> systemd-logind seems to use `/bin/false` here, indicating that my check
> might be overkill and elogind could just use the same as, I guess, dbus
> isn't executing that line if the service is already provided "somehow".
> (But as said, no real dbus knowledge to speak of)
> 
> If you could test that and/or if that works I think it would be a lot
> better to change elogind than to guess what a reasonable timeout may be
> from our side (which is likely a lot longer still than "instant") as
> that seems rather brittle.
> 

I'm not familiar with dbus, nor with elogind.  Perhaps the elogind
maintainers wrote that manifest that way for a reason, perhaps it's a
misconfiguration, but I don't know and frankly don't care, because I
don't need elogind, but I need apt to be fast.

Let me summarize: at some point the APT developers decided to

1. implement shutdown inhibition through dbus

2. enable it by default

3. forget to mention the option DPkg::Inhibit-Shutdown

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).

In fact, there's a middle ground of people that cannot search in the
source code, but are willing to look at the manuals in order to solve
their problem, _especially_ if their scenario is not very common.

What I fail to understand is the reluctance to adopt the simplest
solution, i.e. fix (3).  It is an APT issue: don't try to divert it to
other packages, don't propose changes to other packages' configurations,
just let people know how to bypass a possibly useless and time-consuming
step.

The more I think about (1) and (2), the more it looks regrettable.

Best regards,
	g.