bug#44669: closed (Shepherd loses track of elogind)

[GNU bug Tracking System]

Your message dated Wed, 18 Nov 2020 22:41:43 +0100
with message-id <87mtzebaw8.fsf@gnu.org>
and subject line Re: bug#44669: Shepherd loses track of elogind
has caused the debbugs.gnu.org bug report #44669,
regarding Shepherd loses track of elogind
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
44669: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44669
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: Shepherd loses track of elogind Date: Sun, 15 Nov 2020 22:51:17 +0100

Hello,

On a newly-installed i7 system, Shepherd believes that the "elogind"
service is not running.  Yet there is an 'elogind-daemon' process,
spawned by PID 1, preventing subsequent "herd start elogind" invocations
from succeeding.

signature.asc
Description: PGP signature

--- End Message ---

--- Begin Message --- Subject: Re: bug#44669: Shepherd loses track of elogind Date: Wed, 18 Nov 2020 22:41:43 +0100

Ludovic Courtès <ludo@gnu.org> skriver:

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

Right.  If Shepherd actually deletes the PID file before attempting to
start the service, I think I just "won" the race in my testing...

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

Interesting.  I wonder what other workarounds there are for this.

For now, I made SDDM simply depend on elogind in commit
0ae9bbe4f5f89e6f597bdb1f6df646fc5f504876.

signature.asc
Description: PGP signature

--- End Message ---