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.
