Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: How to setup a local s6-rc database and plug it into the supervision tree (Read 10755 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: How to setup a local s6-rc database and plug it into the supervision tree

Reply #15 –
Quote
Like this?
Code: [Select]
USER=abc
USER2=cde
But wouldn't this require to modify all the execline scripts?

Pretty much. Like runit, s6 services are intended to be one service = one process; therefore, an additional s6-svscan longrun and s6-rc oneshot, importing the USER2 variable, would be needed.

Quote
Is it possible to create some s6 adminsv service, to bring up the local services just for the current user that logs in (and stopping them on logout)? So that you don't have to specify each user individually in user-services.conf. I have the feeling that this might not be possible as adminsv service, but perhaps it is possible to put something like this in the .bash_profile
Code: [Select]
s6-rc -l /tmp/${USER}/s6-rc -up change default
and it just works without specifying each user individually?

adminsv isn't completely out of question yet. Simplifying s6-rc-user's up to:

Code: [Select]
#!/bin/execlineb -P
envfile /etc/s6/config/user-services.conf
importas -uD "username" USER USER
s6-setuidgid ${USER} s6-rc-init -c /home/${USER}/.local/share/s6/rc/compiled -l /tmp/${USER}/s6-rc /tmp/${USER}/service

and leaving each users' s6-svscan/s6-rc on the default bundle is fine,  since s6-rc-init by itself doesn't bring up any services.

I'd add .bash_profile might not be the best place since (1) it's run every time a terminal is open (2) s6-rc -up change default will close all non-default services due to the -p option (3) the logout question is still left unanswered.

The ideal place for what you're suggesting would be a PAM module, which is, in fact, able to be handle login and logout. There's a niche Linux distro called Chimaera Linux using the PAM module idea as we speak (but for dinit, and no easy way to use s6 with it).and First-login and last-logout hooks on elogind would be nicer, though.

Hey, can't we try that with a modified pam_rundir? Calling "bonus section" script on login and s6-svscanctl -t /tmp/$USER/service on logout? /run/user/$UID/{service,s6-rc} instead of /tmp/$USER/{service,s6-rc looks interesting, even.

Quote
What is the advantage of plugging the local user database into the root supervision tree?
I have the feeling it might be more easy to use the bonus section to implement what I imagine.

The bonus section is definitely easier. However, plugging in the root tree gives you supervision (already mentioned), you get to learn about how important environment variables are, and a predictable environment, independent of your .bashrc and co, for your services.

Quote
Another question: How should logs be handled with this method? Using the example from above, should you create a local udiskie-log service? Or are the logs automatically handled by the adminsv services? And if you want to create an individual udiskie-log service, what is the preferred/advised location to save user-specific logs?

I save my user logs on $HOME/.var/log folder created by Flatpak, because... why not. I created both a s6-svscan-capezotte-log service on adminsv (to ~/.var/log/uncaught-logs), and individual logger services on ~/.local/share/s6/sv (on ~/.var/log/dbus, ~/.var/log/gpg-agent, etc.). This is by no means an official recommendation by Skarnet or dudemanguy, that's what seemed logical to me.

Just the first approach is enough, since it prevents user logs from being sent to the root-only /run/uncaught-logs folder. The second makes a nice bonus, but isn't full without the first.

Re: How to setup a local s6-rc database and plug it into the supervision tree

Reply #16 –
Ok, this took me far too long to set up, but everything works now, so thanks you two!  :)

Re: How to setup a local s6-rc database and plug it into the supervision tree

Reply #17 –
Just discovered this place. A note for others (I've discussed this with Dudemanguy on IRC): it is better to avoid using service names with prefixes s6rc- or s6-rc- as they are reserved according to this doc. Nothing seems to break because of this for now, though.

Re: How to setup a local s6-rc database and plug it into the supervision tree

Reply #18 –
So actually, "s6-rc-user" working at all was a bug. The newest s6-rc release has fixed this. I'll go ahead and rename the examples to "local-s6-user" and "local-s6-rc-user".