[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#74912: Shepherd: Growing number of user shepherds when relogging
From: |
Ludovic Courtès |
Subject: |
bug#74912: Shepherd: Growing number of user shepherds when relogging |
Date: |
Thu, 26 Dec 2024 11:50:00 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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’.