bug#44669: Shepherd loses track of elogind

[Ludovic Courtès]

Hi!

Marius Bakke <marius@gnu.org> skribis:

> Indeed.  It was because I had 'sddm-service-type' configured, which
> attempted to communicate with "org.freedesktop.login1" over D-Bus, which
> in turn autostarted elogind before shepherd had gotten around to it.

Oh.

> Now I no longer use SDDM (or any DM), but I was able to work around it
> by adding #:pid-file:
>
> diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
> index 265cf9f35f..6b7d832a44 100644
> --- a/gnu/services/desktop.scm
> +++ b/gnu/services/desktop.scm
> @@ -770,7 +770,8 @@ seats.)"
>                     #:environment-variables
>                     (list (string-append "ELOGIND_CONF_FILE="
>                                          #$(elogind-configuration-file
> -                                           config)))))
> +                                           config)))
> +                   #:pid-file "/run/systemd/elogind.pid"))
>           (stop #~(make-kill-destructor)))))

LGTM.  Now, if elogind is started behind the shepherd’s back, there’s
still a race: shepherd removes the PID file before spawning the process,
and then waits for that PID file to show up.  Chances are shepherd will
not notice that another elogind is already running, and thus the service
will fail to start.

> The race between D-Bus and elogind should probably be handled by having
> org.freedesktop.login1 consumers depend on the 'elogind' service instead?

Yes, we could do that.  Note that the only reason we just don’t let
elogind be bus-activated is so it can handle events like lid close even
before someone has attempted to log in (commit
94a881178af9a9a918ce6de55641daa245c92e73,
<https://issues.guix.gnu.org/27580>).

Thanks,
Ludo’.