> Not sure what you mean by "instantiated services". But see below.
See here:
https://skarnet.org/software/s6/instances.html.
> Sorry for my tone, I realize I was grumpy, possibly offensively so. You
> took it well, thanks. 🙂
No worries, in my opinion the focus should be on being more resilient
and less careful when talking anyway. I think that allows for more
direct and efficient communication.
Also, you were right.
> While I don't know why one would want to differentiate between those,
> you probably can do that quite straightforwardly with pam_exec(8)
Many probably do not need pipewire, mpd or even dbus started when just
ssh'ing into a system.
Also see Bercot's comment here:
https://skarnet.org/lists/supervision/3121.html (paragraph 2).
> 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.
If I get it right, this is what the instantiated services are supposed
to resolve automagically.
All that's left is the requirement of the user configuring hist
autostarts, and if he doesn't, nothing will be instantiated and no
overhead is generated.
> 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"
Amazing, thank you, I will look into that as soon as I can!
Paul
Received on Mon Jul 08 2024 - 15:10:38 CEST