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

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 18 Nov 2020 21:42:03 +0000

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 [email-masked].

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

Subject: Re: bug#44669: Shepherd loses track of elogind
From: Marius Bakke <[email-masked]>
To: Ludovic Courtès <[email-masked]>
Cc: [email-masked]
Date: Wed, 18 Nov 2020 22:41:43 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Ludovic Courtès <[email-masked]> 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.

Subject: Shepherd loses track of elogind
From: Marius Bakke <[email-masked]>
To: [email-masked]
Date: Sun, 15 Nov 2020 22:51:17 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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.