Paul Sopka schrob:
> An alternative would be two main bundles per user service tree, that itself
> always starts on boot:
>
> One to start at boot time.
> Another one to start on first login and stop on last login.
> This seems the most elegant and efficient. Am I overlooking anything?
I am not too familiar with s6 bundles (I use runit, not s6), but that
sounds reasonable.
> > This sounds unnecessarily complicated. Why not simply test for existence
> > of a well-known entry point somewhere in $HOME and let that set up the
> > user supervision tree however it sees fit (or not at all)?
>
> If I understand correctly, this would only be possible using instantiated
> services, I like the idea and I am looking into this.
Not sure what you mean by "instantiated services". But see below.
> > Ugh. I hate this thinking. [...]
>
> It looks like I just do not have enough experience, that's why I am asking
> you all on those points. You are right.
Sorry for my tone, I realize I was grumpy, possibly offensively so. You
took it well, thanks. :)
> Using the idea I stated above, one could use different PAM modules to start
> different bundles tho, e.g. an ssh bundle on ssh login, a getty bundle on
> getty login, a greetd bundle on greetd login.
While I don't know why one would want to differentiate between those,
you probably can do that quite straightforwardly with pam_exec(8)
calling a tiny script that tracks the number of active sessions (of type
"$1") and calls s6-rc on zeroes.
And if you want to make this machinery user-customizable, you'll need
three user entry points:
~/.foo/supervisor
defaulting to "s6-svscan $scandir"
~/.foo/login <type> <concurrent>
defaulting to "if $concurrent == 0 then s6-rc start $type"
~/.foo/logout <type> <concurrent>
defaulting to "if $concurrent == 0 then s6-rc stop $type"
And you'll need one admin action which creates the service supervising
~$USER/.foo/supervisor (if that service doesn't exist yet). To be
triggered on user account creation, or probably on login if things like
ldap are involved.
regards,
Jan
Received on Mon Jul 08 2024 - 12:48:37 CEST