Subject: bug#55444: closed (Re: bug#55444: elogind startup race between shepherd and dbus-daemon)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 28 May 2022 21:27:02 +0000

Your bug report

#55444: elogind startup race between shepherd and dbus-daemon

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
55444: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55444
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#55444: elogind startup race between shepherd and dbus-daemon
From: Ludovic Courtès <[email-masked]>
To: Josselin Poiret <[email-masked]>
Cc: [email-masked]
Date: Sat, 28 May 2022 23:26:23 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

Josselin Poiret <[email-masked]> skribis:

> Great idea!  The patch LGTM, although I'd argue that most of the wrapper
> code could belong in (gnu services herd), in something like
> (wait-for-services #:select? select? #:retries (n 20)) so that someone
> else doesn't end up recoding this for another service.

Good idea, done here:

  f383838a09 services: elogind: When started by dbus-daemon, wait for the Shepherd service.
  b04ae71def services: herd: Add 'wait-for-service'.

Let me know what you think!

Thanks,
Ludo’.

Subject: elogind startup race between shepherd and dbus-daemon
From: Ludovic Courtès <[email-masked]>
To: [email-masked]
Date: Mon, 16 May 2022 10:26:15 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello!

Currently (40a729a0e6f1d660b942241416c1e2c567616d4d), shepherd and
dbus-daemon compete to start elogind: shepherd tries to start it
eagerly, and dbus-daemon starts it on-demand upon bus activation.

Sometimes dbus-daemon wins, and thus shepherd tries a few times to start
it anyway, leading to the infamous:

  elogind is already running as PID 123

(elogind checks whether its PID file exists.  Note that you may see that
message also when shepherd wins, because dbus-daemon tries to start it
anyway.)  Eventually, shepherd considers that elogind cannot be started
and disables it.

In addition to being ridiculous, it’s harmful: the ‘xorg-server’ service
(from ‘gdm-service-type’ and ‘sddm-service-type’ depends on ‘elogind’),
so if shepherd loses the race, Xorg isn’t started (on my laptop,
shepherd never loses the race it seems, but i’ve seen it lose half of
the time on a slower machine).

The reason elogind is started by shepherd is explained in this comment:

       ;; Start elogind from the Shepherd rather than waiting
       ;; for bus activation.  This ensures that it can handle
       ;; events like lid close, etc.

This comes from 94a881178af9a9a918ce6de55641daa245c92e73, which was a
fix for <http://issues.guix.gnu.org/27580>.  I believe the justification
still holds.

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

Depending on what we end up with, we might also revisit whether
xorg-server needs to explicitly depend on elogind.

Thoughts?

Ludo’.