Subject: bug#74912: bug#76998: Guix Home leaves user shepherd on logout, starts new instance on login

From: Tomas Volf <[email-masked]>
Date: Sun, 15 Jun 2025 15:40:33 +0200

Hello :)

Ludovic Courtès <[email-masked]> writes:

>> In any case, what shepherd 1.0.4 does is stop the bleeding, but not fix the problem:
>> It prevents two (or 100) user shepherds for the same user from running in parallel.
>> It does not stop shepherd when a user closed all their sessions.
>
> Yes.  It just occurred to me that we probably just got it wrong from the
> start: ‘XDG_RUNTIME_DIR’ (/run/user/$UID) is specified as having limited
> lifetime.  Quoth
> <https://specifications.freedesktop.org/basedir-spec/latest/>:
>
>   The lifetime of the directory MUST be bound to the user being logged
>   in.  It MUST be created when the user first logs in and if the user
>   fully logs out the directory MUST be removed.
>
> So it was probably a bad idea in the first place for shepherd to store
> its socket in /run/user/$UID (even more so that this directory doesn’t
> exist on systems without elogind/systemd).  GnuPG avoids
> $XDG_RUNTIME_DIR for exactly this reason (there’s a comment in
> ‘homedir.c’).

Minor correction here.  Looking at the source code, GnuPG avoids the
XDG_RUNTIME_DIR environment variable, but it still tries to use the
/run/user/$UID directory, if it exists.

> So, what can we do?
>
> In the Shepherd 1.1, we could default to $XDG_STATE_HOME instead; we
> probably shouldn’t change that in 1.0.x.

Not sure here, the specification says the following about this location:

> The $XDG_STATE_HOME contains state data that *should persist between
> (application) restarts*, but that is not important or portable enough
> to the user that it should be stored in $XDG_DATA_HOME.

So... control socket does not seem to fit that description.

> Any other idea?

Well, since you have mentioned the GnuPG as an example, we could just
mirror what it does, and what I have suggested before.

--8<---------------cut here---------------start------------->8---
$ mkdir /tmp/xxx && cd /tmp/xxx
$ guix shell -u test -C findutils gnupg coreutils bash procps -- env HOME=/tmp/xxx GNUPGHOME=/tmp/xxx bash
test@xx ~ [env]$ gpg-agent --daemon
gpg-agent[2]: directory '/tmp/xxx/private-keys-v1.d' created
gpg-agent[3]: gpg-agent (GnuPG) 2.4.7 started
test@xx ~ [env]$ find /run/user
/run/user
/run/user/1000
/run/user/1000/gnupg
/run/user/1000/gnupg/d.j1yiifhhjrep9xunazyff54c
/run/user/1000/gnupg/d.j1yiifhhjrep9xunazyff54c/S.gpg-agent.ssh
/run/user/1000/gnupg/d.j1yiifhhjrep9xunazyff54c/S.gpg-agent.browser
/run/user/1000/gnupg/d.j1yiifhhjrep9xunazyff54c/S.gpg-agent.extra
/run/user/1000/gnupg/d.j1yiifhhjrep9xunazyff54c/S.gpg-agent
test@xx ~ [env]$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
test         1  0.0  0.0   5136  4068 ?        S    13:32   0:00 bash
test         3  0.0  0.0   5516  2400 ?        Ss   13:32   0:00 gpg-agent --daemon
test         5  0.0  0.0   5224  3852 ?        R+   13:32   0:00 ps aux
test@xx ~ [env]$ rm -r /run/user/1000/gnupg
gpg-agent[3]: socket file has been removed - shutting down
gpg-agent[3]: gpg-agent (GnuPG) 2.4.7 stopped
test@xx ~ [env]$ find /run/user
/run/user
/run/user/1000
test@xx ~ [env]$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
test         1  0.0  0.0   5136  4068 ?        S    13:32   0:00 bash
test         8  0.0  0.0   5224  3776 ?        R+   13:33   0:00 ps aux
--8<---------------cut here---------------end--------------->8---

So my suggestion is that when the socket is deleted, the shepherd
process stops itself.

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.