Hey there, Ludovic Courtès skribis: > So it would seem that the solution to this is to prevent dbus-daemon > from starting elogind. We can do that by changing > org.freedesktop.login1.service so that it has “Exec=true” instead of > “Exec=elogind --daemon”. > > “Exec=true” is a bit crude because it doesn’t guarantee that elogind is > really started; if that isn’t good enough, we could instead wait for the > PID file or something (as of Shepherd 0.9.0, invoking ‘herd start > elogind’ potentially leads shepherd to start a second instance if the > first one is still being started, so we can’t really do that). The patch below address that: it changes the “Exec=” line of ‘org.freedesktop.login1’ to refer to a wrapper. That wrapper connects to shepherd and waits until ‘elogind’ is started. That way, if dbus-daemon comes first, it won’t actually launch anything and instead wait for the Shepherd ‘elogind’ service to be up. (And if it comes second, dbus-daemon won’t try to launch anything, so no spurious “already running” messages.) I tested it in a ‘desktop.tmpl’ VM, quickly logging in on tty1. On /var/log/messages, you can see the “Activating ….login1” message from dbus-daemon, followed by “Service elogind started” from shepherd, followed by “Successfully activated ….login1” from dbus-daemon. The “elogind” system test passes too. Thoughts? Objections? Ludo’.