GNU bug report logs - #76998
Guix Home leaves user shepherd on logout, starts new instance on login

Previous Next

Full log

View this message in rfc822 format

From: Danny Milosavljevic <dannym <at> friendly-machines.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 74912 <at> debbugs.gnu.org, 76998 <at> debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>, 76998-done <at> debbugs.gnu.org, Jake <jforst.mailman <at> gmail.com>, Daniel Littlewood <dan <at> danielittlewood.xyz>
Subject: bug#76998: Guix Home leaves user shepherd on logout, starts new instance on login
Date: Tue, 17 Jun 2025 00:53:35 +0200

Hi Ludo,

First, I apologize for the tone back that day.  Sorry!

Hmm, I think using inotify is nice, but I don't think it's guaranteed to block the deletion of the socket (and thus the dismantling of the entire user scope) on a notification.  That doesn't have to be bad--but it means that whatever stopping of user services shepherd does are in parallel to (and possibly later than!) the cleanup elogind and/or systemd does.  elogind/systemd could totally (and probably do!) remove the floor from the underneath shepherd while it's still busy stopping services (and syncing user service stuff to disk etc).

I don't see obvious actionable downsides, but some potential for stuff going wrong.

Frankly, this is some really weird patchwork GNU/Linux is doing there.  There's a reason systemd is the service manager integrating almost everything slightly (in different cooperating processes, though) and it's not just because they are weird.

But I'd say for now we can totally do the inotify thing and handle problems as they arise.

That said, patching elogind (for example just the herd stop root thing) would be easy enough too--but wouldn't help on other distros.

Maybe we can future-proof shepherd a bit (if we don't already): If we wanted to change the mechanism later (to elogind, or to whatever) in the future it it could get hairy to decide who's responsible for stopping shepherd now.  So we should definitely figure out if we are already stopping shepherd--and not begin stopping shepherd again while we are busy stopping shepherd :)

As for gnupg, it's a lot easier to stop gnupg since it isn't responsible for stopping like half the machine in an orderly fashion, than it is shepherd. :)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.