bug#74912: Shepherd: Growing number of user shepherds when relogging

[Tomas Volf]

Ludovic Courtès <ludo@gnu.org> 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.

signature.asc
Description: PGP signature