Ludovic Courtès writes: > 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? I believe it is done by elogind (in my setup) when last user session (for the given UID) logs out. If I grepped right, it is done by user_finalize function in logind-user.c. It (AFAIUT) it should be performed when last session of the seat terminates. So if you log only into a single TTY, the XDG_RUNTIME_DIR will be removed on every log out. > >> 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? I looked around the manual page, but did not found anything. There is KillUserProcesses, but that feels like fairly big hammer, and something that should *not* be enabled by default. We could patch elogind to add new RemoveRuntimeDirectory boolean flag to allow keeping the XDG_RUNTIME_DIR even after last log out (I personally would prefer that behavior anyway). I am not sure what our policy regarding patches here is. > > 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. No idea here. ~/.bash_logout? > >> 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. For files I would suggest checking if both `stat:dev' and `stat:ino' match in order to detect whether it is the same file. Not sure if same strategy can be used for unix sockets. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.