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>
Subject: bug#44669: closed (Re: bug#44669: Shepherd loses track of elogind)
Date: Wed, 18 Nov 2020 21:42:03 +0000

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

Your bug report

#44669: Shepherd loses track of elogind

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 44669 <at> debbugs.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: 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 3 (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)]

[Message part 5 (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 6 (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)]

Previous Next

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