Subject: bug#67863: closed (Re: bug#76998: Guix Home leaves user shepherd on logout, starts new instance on login)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 14 Jun 2025 21:28:03 +0000

Your bug report

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

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
76998: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76998
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#76998: Guix Home leaves user shepherd on logout, starts new instance on login
From: Ludovic Courtès <[email-masked]>
To: Danny Milosavljevic <[email-masked]>
Cc: [email-masked], [email-masked], Tomas Volf <[email-masked]>, [email-masked], Jake <[email-masked]>, Daniel Littlewood <[email-masked]>
Date: Sat, 14 Jun 2025 23:26:53 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi Danny,

Danny Milosavljevic <[email-masked]> writes:

> It's good that the "is a shepherd already running" check is back in
> shepherd.  It was in shepherd years ago, then got removed without
> explanation, then now it's back again (now in a very convoluted but
> safer way).  This shouldn't have been removed in the first place.
> It's EXTREMELY dangerous to have multiple parallel shepherds for the
> same user (automated backup service destroying backups etc).  Please,
> let's not remove it ever again.

If you’re referring to 649a98a6697d358a53eccc45b387e5130278b5ec (8 years
ago), I believe it wasn’t doing just that due to lingering.

(Aside: I think the tone of this paragraph is uncalled for.)

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

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.

Any other idea?

Thanks,
Ludo’.

Subject: Guix Home: Multiple instances of user Shepherd created
From: [email-masked]
To: "[email-masked]" <[email-masked]>
Date: Sat, 16 Dec 2023 23:42:04 +0100 (CET)
List-Id: <debbugs-submit.debbugs.gnu.org>

I am trying to use the awesome Guix Home Shepherd service for syncthing (home-syncthing-service-type).
 
Syncthing works fine but every time I log out of my last user session and log back in again, a new instance of the user shepherd is started (and tries to start syncthing again).
After logging out and in a few times, there are multiple user shepherd processes.
 
Suspected cause:  Apparently the user shepherd process is not killed on last logout before elogind (correctly) removes XDG_RUNTIME_DIR.
So on next login, a new empty XDG_RUNTIME_DIR is created, causing a new user shepherd to be started while the old one is still running happily.
This seems to be a general issue and not particular to the syncthing home service.
 
System: Guix System on x86_64
Guix commit: ac61e9705fb8c450c6cd0c1731fbb1b909c1f944
 
--
Uli