Re: Should Guix Home daemonize Shepherd?

[Kevin Boulain]

So, I've done some digging and I'm coming back with two findings :)

First, Guix Home correctly tells the user Shepherd to daemonize itself
via an 'action'
(https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm#n64)
but, from my understanding, the daemonization process is missing at
least a setsid call
(https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1421),
see the attached 'shepherd-setsid.patch'. This fixes the Shepherd
dying when exiting the SSH session or the Shepherd catching the ^C.
I guess it should also close std{in,out,err} like it's done for the
regular services
(https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n806)
but this answers a part of my initial post.

Second, elogind (it's required by Guix Home to get the XDG_*
environment variables and also part of %desktop-services) will remove
/run/user/$uid when the session ends. It's standard, but the problem
is that Guix Home's 'on-first-login-executed' is located there,
alongside 'shepherd/socket' and probably the other user daemon's
sockets. This easily results in duplicate services being rerun when
the old ones haven't been killed because 'KillUserProcesses' is set to
'no' by default
(https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/desktop.scm#n937).
I don't think it's a bad idea to set KillUserProcesses=no (I remember
that when this was first introduced a lot of users complained, see for
example https://github.com/tmux/tmux/issues/428) but now we're in an
awkward position unless Guix Home users move everything out of
XDG_RUNTIME_DIR (for example, tmux's socket is in /tmp).

Thoughts? I must admit, I'm not sure how to address the elogind issue,
XDG_RUNTIME_DIR is ingrained in a lot of places (even in the Shepherd
https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/support.scm#n284)
and asking users to override socket flags (and others) for all the
services they run (if at all possible) sounds a bit counterintuitive.
Or am I missing something obvious?

shepherd-setsid.patch
Description: Binary data