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. Best regards David Kalnischkies
signature.asc
Description: PGP signature
