Hello :) Ludovic Courtès <[email protected]> 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.
