unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#44669: Shepherd loses track of elogind
@ 2020-11-15 21:51 Marius Bakke
  2020-11-16 14:58 ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: Marius Bakke @ 2020-11-15 21:51 UTC (permalink / raw)
  To: 44669

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#44669: Shepherd loses track of elogind
  2020-11-15 21:51 bug#44669: Shepherd loses track of elogind Marius Bakke
@ 2020-11-16 14:58 ` Ludovic Courtès
  2020-11-16 17:37   ` Marius Bakke
  0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2020-11-16 14:58 UTC (permalink / raw)
  To: Marius Bakke; +Cc: 44669

Hi Marius,

Marius Bakke <marius@gnu.org> skribis:

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

Could you show the relevant /var/log/messages bits?  That should show
when/why elogind stopped.

That’s from 1.2.0rc1?

Thanks,
Ludo’.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#44669: Shepherd loses track of elogind
  2020-11-16 14:58 ` Ludovic Courtès
@ 2020-11-16 17:37   ` Marius Bakke
  2020-11-16 17:49     ` Marius Bakke
  2020-11-17  8:31     ` Ludovic Courtès
  0 siblings, 2 replies; 6+ messages in thread
From: Marius Bakke @ 2020-11-16 17:37 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 44669


[-- Attachment #1.1: Type: text/plain, Size: 669 bytes --]

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

> Hi Marius,
>
> Marius Bakke <marius@gnu.org> skribis:
>
>> 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.
>
> Could you show the relevant /var/log/messages bits?  That should show
> when/why elogind stopped.

Indeed.  It was because I had 'sddm-service-type' configured, which
attempted to communicate with "org.freedesktop.login1" over D-Bus, which
in turn autostarted elogind before shepherd had gotten around to it.


[-- Attachment #1.2: elogind.log --]
[-- Type: text/plain, Size: 1602 bytes --]

Nov 15 21:16:18 localhost dbus-daemon[427]: [system] Activating service name='org.freedesktop.login1' requested by ':1.2' (uid=0 pid=449 comm="/gnu/store/x577n8rs9zcf6ri4aka4pccyj74qxhwh-sddm-0") (using servicehelper)
Nov 15 21:16:18 localhost vmunix: [   46.137561] elogind-daemon[462]: New seat seat0.
Nov 15 21:16:18 localhost vmunix: [   46.138052] elogind-daemon[462]: Watching system buttons on /dev/input/event2 (Power Button)
Nov 15 21:16:18 localhost vmunix: [   46.193372] elogind-daemon[462]: Watching system buttons on /dev/input/event1 (Lid Switch)
Nov 15 21:16:18 localhost vmunix: [   46.193428] elogind-daemon[462]: Watching system buttons on /dev/input/event0 (Sleep Button)
Nov 15 21:16:18 localhost avahi-daemon[444]: Server startup complete. Host name is sirius.local. Local service cookie is 3083842416.
Nov 15 21:16:18 localhost vmunix: [   46.496547] elogind-daemon[462]: Watching system buttons on /dev/input/event3 (AT Translated Set 2 keyboard)
Nov 15 21:16:18 localhost vmunix: [   46.496598] elogind-daemon[462]: Watching system buttons on /dev/input/event4 (ThinkPad Extra Buttons)
Nov 15 21:16:18 localhost dbus-daemon[427]: [system] Successfully activated service 'org.freedesktop.login1'
Nov 15 21:16:18 localhost vmunix: [   46.498084] elogind-daemon[462]: New session c1 of user marius.
Nov 15 21:16:18 localhost shepherd[1]: Service avahi-daemon has been started.
Nov 15 21:16:18 localhost shepherd[1]: Service mcron has been started.
Nov 15 21:16:18 localhost shepherd[1]: Service elogind has been started.
Nov 15 21:16:18 localhost shepherd[1]: Respawning elogind.

[-- Attachment #1.3: Type: text/plain, Size: 273 bytes --]


> That’s from 1.2.0rc1?

Yes, and also 'master'.  The initial i3 install with 1.2.0rc1 went fine,
it was when I switched to SDDM + autologin (+ sway) that it failed.

Now I no longer use SDDM (or any DM), but I was able to work around it
by adding #:pid-file:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.4: diff --]
[-- Type: text/x-patch, Size: 630 bytes --]

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)))))
 
 (define elogind-service-type

[-- Attachment #1.5: Type: text/plain, Size: 147 bytes --]


The race between D-Bus and elogind should probably be handled by having
org.freedesktop.login1 consumers depend on the 'elogind' service instead?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* bug#44669: Shepherd loses track of elogind
  2020-11-16 17:37   ` Marius Bakke
@ 2020-11-16 17:49     ` Marius Bakke
  2020-11-17  8:31     ` Ludovic Courtès
  1 sibling, 0 replies; 6+ messages in thread
From: Marius Bakke @ 2020-11-16 17:49 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 44669

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Marius Bakke <marius@gnu.org> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Marius,
>>
>> Marius Bakke <marius@gnu.org> skribis:
>>
>>> 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.
>>
>> Could you show the relevant /var/log/messages bits?  That should show
>> when/why elogind stopped.
>
> Indeed.  It was because I had 'sddm-service-type' configured, which
> attempted to communicate with "org.freedesktop.login1" over D-Bus, which
> in turn autostarted elogind before shepherd had gotten around to it.

Interestingly I suspected this exact scenario and checked the PPID of
the running elogind process, which was '1'.  When I then found that
adding #:pid-file worked, I did not bother checking the log ...

I would have expected D-Bus to be the parent PID.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#44669: Shepherd loses track of elogind
  2020-11-16 17:37   ` Marius Bakke
  2020-11-16 17:49     ` Marius Bakke
@ 2020-11-17  8:31     ` Ludovic Courtès
  2020-11-18 21:41       ` Marius Bakke
  1 sibling, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2020-11-17  8:31 UTC (permalink / raw)
  To: Marius Bakke; +Cc: 44669

Hi!

Marius Bakke <marius@gnu.org> skribis:

> Indeed.  It was because I had 'sddm-service-type' configured, which
> attempted to communicate with "org.freedesktop.login1" over D-Bus, which
> in turn autostarted elogind before shepherd had gotten around to it.

Oh.

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

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

Thanks,
Ludo’.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#44669: Shepherd loses track of elogind
  2020-11-17  8:31     ` Ludovic Courtès
@ 2020-11-18 21:41       ` Marius Bakke
  0 siblings, 0 replies; 6+ messages in thread
From: Marius Bakke @ 2020-11-18 21:41 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 44669-done

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-11-18 21:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-15 21:51 bug#44669: Shepherd loses track of elogind Marius Bakke
2020-11-16 14:58 ` Ludovic Courtès
2020-11-16 17:37   ` Marius Bakke
2020-11-16 17:49     ` Marius Bakke
2020-11-17  8:31     ` Ludovic Courtès
2020-11-18 21:41       ` Marius Bakke

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).