guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should Guix Home daemonize Shepherd?


From: Andrew Tropin
Subject: Re: Should Guix Home daemonize Shepherd?
Date: Fri, 06 May 2022 11:07:25 +0300

On 2022-03-12 18:49, Kevin Boulain wrote:

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

CCed Leo, Ludovic and Carlo.

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

Actually, XDG_RUNTIME_DIR can be provided not only by elogind, but also
by pam_rundir or something similar, however in general it's true,
runtime dir will be removed when 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.

This is a tough question, faced it when only started to work on Guix
Home.  One idea I had back in the days is to have a possibility to get
lingering user shepherd, which starts on boot, the implementation
doesn't seem trivial so I decided to postpone experiments in this
direction for a better times.  Not sure if it's any perfect, but at
least is something to think about.

> Or am I missing something obvious?
> Detach from the controlling terminal when daemonizing
>
> https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00040.html
>
> diff --git c/modules/shepherd/service.scm w/modules/shepherd/service.scm
> index ad8608b..62f97bc 100644
> --- c/modules/shepherd/service.scm
> +++ w/modules/shepherd/service.scm
> @@ -1420,8 +1420,12 @@ we want to receive these signals."
>            (else
>             (if (zero? (primitive-fork))
>                 (begin
> -                 (catch-system-error (prctl PR_SET_CHILD_SUBREAPER 1))
> -                 #t)
> +                 (setsid)
> +                 (if (zero? (primitive-fork))
> +                     (begin
> +                       (catch-system-error (prctl PR_SET_CHILD_SUBREAPER 1))
> +                       #t)
> +                     (primitive-exit 0)))
>                 (primitive-exit 0))))))
>       (persistency
>        "Save the current state of running and non-running services.

-- 
Best regards,
Andrew Tropin

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]