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

Previous Next

Full log

Message #17 received at 74912 <at> debbugs.gnu.org (full text, mbox):

From: bokr <at> bokr.com
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Jake <jforst.mailman <at> gmail.com>, 74912 <at> debbugs.gnu.org,
 Tomas Volf <~@wolfsden.cz>
Subject: Re: bug#74912: Shepherd: Growing number of user shepherds when
 relogging
Date: Thu, 26 Dec 2024 09:25:18 -0800

On +2024-12-26 11:50:00 +0100, Ludovic Courtès wrote:
> Hi!
> 
> Tomas Volf <~@wolfsden.cz> skribis:
> 
> > When you have another login session active when you log out and in
> > again, new shepherd is *not* spawned.  I am guessing here but probably
> > last log out causes XDG_RUNTIME_DIR to be removed (by elogind in my
> > case), so on log in there is no /run/user/$UID/on-first-login-executed,
> > so it runs again and starts the shepherd.
> >
> > But even if that would be solved, since the runtime directory was nuked,
> > there is no shepherd socket around anymore, so the (still running)
> > shepherd from previous login session cannot be contacted by herd.
> 
> Hmm, when is /run/user/UID deleted?
> 
> > Of the top of my head I can think of two possible solutions:
> >
> > 1. Stop the shepherd on log out.  So as we have on-first-login, we would
> > have on-last-logout.  I have no idea how to implement that.  Maybe we
> > could use ~/.bash_logout?  Or some PAM thing?
> 
> Or some elogind thing, rather?
> 
> But then, how do we make it work on other distros?  Maybe on systemd
> distros shepherd receives SIGTERM or something, in which case it
> terminates properly.
> 
> > 2. Shepherd could shutdown gracefully when the control socket is deleted
> > from the file system.  It is arguable how useful running shepherd is
> > without the socket anyway.
> 
> I don’t think that’s workable: you’d need to poll/inotify for the
> existence of that socket, but even if it exists on the file system, you
> cannot tell whether it matches the socket you’re accepting on.
> 
> Ludo’.
> 
> 
> 

I wonder how many guix-daemon-process-relationship type problems would be simplified
if (radical vision) one let wayland's inner event-driven loop/protocol be the dispatcher
for guix processes instead of the current guix daemon switching between its collection of threads.
I.e., all the guix threads would be individual login or spawned user processes securely communicating
virtualizably (shared memory or networked rendezvous buffers etc) for offloading?

Previous Next

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