[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44669: Shepherd loses track of elogind
From: |
Marius Bakke |
Subject: |
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