GNU bug report logs - #44669
Shepherd loses track of elogind

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Marius Bakke <marius <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#44669: closed (Shepherd loses track of elogind)
Date: Wed, 18 Nov 2020 21:42:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 18 Nov 2020 22:41:43 +0100
with message-id <87mtzebaw8.fsf <at> 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 <at> gnu.org.)


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

[Message part 2 (message/rfc822, inline)]

From: Marius Bakke <marius <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: Shepherd loses track of elogind
Date: Sun, 15 Nov 2020 22:51:17 +0100

[Message part 3 (text/plain, inline)]

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 (application/pgp-signature, inline)]

[Message part 5 (message/rfc822, inline)]

From: Marius Bakke <marius <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 44669-done <at> debbugs.gnu.org
Subject: Re: bug#44669: Shepherd loses track of elogind
Date: Wed, 18 Nov 2020 22:41:43 +0100

[Message part 6 (text/plain, inline)]

Ludovic Courtès <ludo <at> 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 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.