Re: s6/s6-rc policy for Gentoo: config files for service scripts
Paul Sopka schrob: > I do not think that providing only this option this is a good idea, > since names are unique and dependencies are declared in the dependent > service. "It simplifies dependencies" sounds like a good reason to go with the tryexec approach. Cheers, Jan signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: config files for service scripts
Overrides? No, this would make things confusing and error-prone. The behaviour of a set of source definition directories should not be influenced by whether or not you're compiling it with another set. Thanks for letting me know! Regards, Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: config files for service scripts
I think there's a misunderstanding here, I'll try again: What I proposed is putting the service definitions into /usr, never copy or link them to /etc, never modify them (except by package updates), and let s6 execute them directly from there. If the local admin wants something other than the service as you ship it, they create a completely new, independent local service and disable the one shipped by you. Thus you can update the definitions in /usr as you see fit, and the admin can override things as they see fit. No machinery needed inside the actual run scripts. I do not think that providing only this option this is a good idea, since names are unique and dependencies are declared in the dependent service. Consider the example of "seatd-srv": The sysadmin disables it and creates "seatd-new-srv", now he has to create a "${SERVICE}-new-srv" for every "${SERVICE}-srv" depending on "seatd-srv" to adjust their dependencies, do the same for every "${SERVICE}-new-srv", ... Of course, this can easily be solved by only ever depending on bundles, thus, one creates "seatd-new-srv" adds it to the bundle "seat-management"(everyone depends on), removes "seatd-srv" from "seat-management" and has exactly what you envisioned. Thus, a policy of "only ever depend on a bundle", which I already employ, is needed. Anyway, I am not sure if all if this additionally requirement is really worth saving one line per service script. A point for your approach is, of course, that the user gains full control over the service he changed, as he is able to change the logging behavior, dependencies, ... That however, requires way more insight into the entire service system, s6 and s6-rc as opposed to "read the script, understand the script, adapt the script, put it in the right place". Regards, Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: config files for service scripts
Paul Sopka schrob: > > > ... then begs the question: what's the advantage of having the > > > ${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort > > > does this save the admin over creating their own my_seatd service and > > > disabling the one you provide? > > > (Honest question, I don't fully grok s6.) > > > > It doesn’t save any effort at all. > I disagree, because it allows original service scripts to sit at > /usr/lib/s6-rc/{user,system}/src/service > and be recklessly updated by the package manager. I think there's a misunderstanding here, I'll try again: What I proposed is putting the service definitions into /usr, never copy or link them to /etc, never modify them (except by package updates), and let s6 execute them directly from there. If the local admin wants something other than the service as you ship it, they create a completely new, independent local service and disable the one shipped by you. Thus you can update the definitions in /usr as you see fit, and the admin can override things as they see fit. No machinery needed inside the actual run scripts. Cheers, Jan signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: config files for service scripts
... then begs the question: what's the advantage of having the ${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort does this save the admin over creating their own my_seatd service and disabling the one you provide? (Honest question, I don't fully grok s6.) It doesn’t save any effort at all. I disagree, because it allows original service scripts to sit at /usr/lib/s6-rc/{user,system}/src/service and be recklessly updated by the package manager. For the record, I’m also in favor of this: the simpler the service scripts, the better in my opinion. They’re easier to understand, simpler to adapt. A short and direct script can be as descriptive as descriptive configuration files sometimes, but better because you actually know everything that takes place. :D I wholeheartedly agree, this is pretty exactly my mindset too. Additionally they are probably faster, since they are smaller and do not need to parse configs. Regards, Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: config files for service scripts
From Jan: That's a more reasonable size than your first example. Although this ... Allowing the sysadmin to completely override the service. Unfortunately this also forces the sysadmin to override the service for every so little change, ... then begs the question: what's the advantage of having the ${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort does this save the admin over creating their own my_seatd service and disabling the one you provide? (Honest question, I don't fully grok s6.) It does not have anything to do with s6 itself, it just allows original service scripts to sit at /usr/lib/s6-rc/{user,system}/src/service and be recklessly updated by the package manager. Installing them initially to /etc/s6-rc/{user,system}/src/service and editing them in place will not allow that. This is in part mitigated by: I am not sure if I understand correctly, the files under /usr/share/s6-rc/{user,system} are to be there only as a reference, not to be edited. Are you trying to say that the non-edited files should be symlinked rather than copied? I was indeed trying to say that. But on second thought: you should do whatever Gentoo usually does with such configuration files. Consistency trumps any minor advantages any particular approach might have. But this introduces needless complexity just to save one line in every script. The best would probably be for s6-rc-compile to allow for multiple definitions of a service, letting later definitions override earlier ones, e.g. s6-rc-compile ${OUTPUT_DB} ${SOURCE_1} ${SOURCE_2} where seatd-srv in ${SOURCE_2} overrides seatd-srv in ${SOURCE_1}. Would this be realizable Laurent? Regards, Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: config files for service scripts
Am Do, Sep 19, 2024 am 07:51:50 +0200 schrieb Jan Braun: Allowing the sysadmin to completely override the service. Unfortunately this also forces the sysadmin to override the service for every so little change, ... then begs the question: what's the advantage of having the ${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort does this save the admin over creating their own my_seatd service and disabling the one you provide? (Honest question, I don't fully grok s6.) It doesn’t save any effort at all. Being able to easily add custom services is a necessity anyway. So maybe don't allow any customization (besides disabling) at all, ship | #!/bin/execlineb -P | fdmove -c 2 1 | seatd -n3 -u root -g seatd and teach users to create new services with the 3rd line changed to whatever they need. For the record, I’m also in favor of this: the simpler the service scripts, the better in my opinion. They’re easier to understand, simpler to adapt. A short and direct script can be as descriptive as descriptive configuration files sometimes, but better because you actually know everything that takes place. :D Hoël signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: config files for service scripts
Paul Sopka schrob: > I am not sure if I understand correctly, the files under > /usr/share/s6-rc/{user,system} > are to be there only as a reference, not to be edited. > Are you trying to say that the non-edited files should be symlinked rather > than copied? I was indeed trying to say that. But on second thought: you should do whatever Gentoo usually does with such configuration files. Consistency trumps any minor advantages any particular approach might have. > Although it has to be done a bit differently when using execline > [...] > Would turn into: > > | #!/bin/execlineb -P > | fdmove -c 2 1 > | importas -SD /etc/s6-rc S6CONFIGDIR > | tryexec ${S6CONFIGDIR}/system/config/seatd > | seatd -n3 -u root -g seatd That's a more reasonable size than your first example. Although this ... > Allowing the sysadmin to completely override the service. > Unfortunately this also forces the sysadmin to override the service for > every so little change, ... then begs the question: what's the advantage of having the ${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort does this save the admin over creating their own my_seatd service and disabling the one you provide? (Honest question, I don't fully grok s6.) Being able to easily add custom services is a necessity anyway. So maybe don't allow any customization (besides disabling) at all, ship | #!/bin/execlineb -P | fdmove -c 2 1 | seatd -n3 -u root -g seatd and teach users to create new services with the 3rd line changed to whatever they need. HTH, Jan signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: config files for service scripts
A skeleton is not config data, and should thus be in /usr/ Possibly /usr/.../examples/... I agree, the reason i put it there ist that /etc/s6-linux-init/skel/ exists (at least on Gentoo Linux), thus for consistency. - The package manager puts service source directories and an initial set of bundles for system services to /etc/s6-rc/system/src/{services,bundles}. - The package manager puts service source directories and an initial set of bundles for both user and system services to /usr/share/s6-rc/{user,system} as a reference of the defaults. If you put defaults in /usr, then prefer symlinking them into /etc, rather than creating a copy. That'll automatically handle changing defaults, and make it obvious what is locally customized. I am not sure if I understand correctly, the files under /usr/share/s6-rc/{user,system} are to be there only as a reference, not to be edited. Are you trying to say that the non-edited files should be symlinked rather than copied? Void has a nice idiom in their run scripts: | #!/bin/sh | exec 2>&1 | [ -r conf ] && . ./conf | exec acpid -f ${OPTS:=-l} That achieves 3 things: 1) It works out of the box (without a conf file). 2) The user can create a conf file containing OPTS='-l -d -S' to customize the daemon options. 3) The user can create a conf file containing if [ $((`date +%s` % 100)) -eq 0 ] ; then poweroff ; fi exec /usr/local/bin/notreallyacpid --foo to completely¹ override the run file. Note how the KEY=value pair in 2) is actually shell, hopefully eliminating any worries about config file format. HTH, Jan ¹) The "exec 2>&1" is an artifact of how runit does logging, and should always be done. Hence it comes before the conf entry point. If there was a valid use for stderr, lines 2 and 3 could be switched, of course. Glorious. Although it has to be done a bit differently when using execline (which I intend to use): Take my current version of the seatd-srv: | #!/bin/execlineb -P | | fdmove -c 2 1 | | multisubstitute | { | define SRV seatd | importas -SD /etc/s6-rc S6CONFIGDIR | } | | envfile -I ${S6CONFIGDIR}/system/config/${SRV}.conf | | multisubstitute | { | importas -SD "root" SEATD_USER | importas -SD "seat" SEATD_GROUP | importas -SD "seatd" SRV_EXEC | importas -sSD "" SRV_OPTS | } | | | ${SRV_EXEC} -n3 | -u ${SEATD_USER} | -g ${SEATD_GROUP} | ${SRV_OPTS} Would turn into: | #!/bin/execlineb -P | | fdmove -c 2 1 | | importas -SD /etc/s6-rc S6CONFIGDIR | | tryexec ${S6CONFIGDIR}/system/config/seatd | | seatd -n3 -u root -g seatd Allowing the sysadmin to completely override the service. Unfortunately this also forces the sysadmin to override the service for every so little change, so your 2) The user can create a conf file containing OPTS='-l -d -S' to customize the daemon options. wont work anymore but I do not see how one could work around this in execline. What do you think? Regards, Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: config files for service scripts
Paul Sopka schrob: > - The sysadmin or the user can copy a skeleton from > /etc/s6-rc/skel/{config,src} (which is populated by the package > manager with configs and initial bundles) to ${HOME}/.config/s6-rc/, > this folder shall be used for configuration and custom user services. A skeleton is not config data, and should thus be in /usr/ Possibly /usr/.../examples/... > - The package manager puts service source directories and an initial > set of bundles for system services to > /etc/s6-rc/system/src/{services,bundles}. > > - The package manager puts service source directories and an initial > set of bundles for both user and system services to > /usr/share/s6-rc/{user,system} as a reference of the defaults. If you put defaults in /usr, then prefer symlinking them into /etc, rather than creating a copy. That'll automatically handle changing defaults, and make it obvious what is locally customized. > - The idea of config files is completely dropped and the "editing the > config" part is shifted to "editing the run-script" > [...] > Do you suggest any alterations or even a completely different approach? Void has a nice idiom in their run scripts: | #!/bin/sh | exec 2>&1 | [ -r conf ] && . ./conf | exec acpid -f ${OPTS:=-l} That achieves 3 things: 1) It works out of the box (without a conf file). 2) The user can create a conf file containing OPTS='-l -d -S' to customize the daemon options. 3) The user can create a conf file containing if [ $((`date +%s` % 100)) -eq 0 ] ; then poweroff ; fi exec /usr/local/bin/notreallyacpid --foo to completely¹ override the run file. Note how the KEY=value pair in 2) is actually shell, hopefully eliminating any worries about config file format. HTH, Jan ¹) The "exec 2>&1" is an artifact of how runit does logging, and should always be done. Hence it comes before the conf entry point. If there was a valid use for stderr, lines 2 and 3 could be switched, of course. signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
Is there an equivalent chainloader ("envfile"-style) that can be plugged into the instanced user service directories' command line? Having the same configuration file be read by tools with different behaviors (for instance, it appears the pam_env's quoting support is far more limited than envfile's) may not lead to the same results. I wanted envfile to be compatible with intuitive and expected behaviour. If you write your files conservatively wrt what other tools accept, you should be able to read them with envfile. -- Laurent
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
Is there an equivalent chainloader ("envfile"-style) that can be plugged into the instanced user service directories' command line? Having the same configuration file be read by tools with different behaviors (for instance, it appears the pam_env's quoting support is far more limited than envfile's) may not lead to the same results. Em seg., 15 de jul. de 2024 06:35, Paul Sopka escreveu: > > There's already pam_env to set environment variables. And from > > pam_env.conf it can expand @{HOME} and presumably ${USER}, which should > > be all you need to accomodate desktop stuff that expects XDG_* and > > Thank you, this looks great! > > Since it can also source a plain key=value file, it can source the same > "config file" I source in the script setting up the user-service tree. > Thus not creating the need to synchronize two config files. > > > Have a nice Monday! > > Paul > >
Re: s6/s6-rc policy for Gentoo: user session tracking
That said, it might be of interest to you, that s6-setlock does not appear here: https://skarnet.org/software/s6/index.html. Whoops. And nobody noticed that in 13 years? Shame on all of you. :P Fixed, thanks! -- Laurent
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
There's already pam_env to set environment variables. And from pam_env.conf it can expand @{HOME} and presumably ${USER}, which should be all you need to accomodate desktop stuff that expects XDG_* and Thank you, this looks great! Since it can also source a plain key=value file, it can source the same "config file" I source in the script setting up the user-service tree. Thus not creating the need to synchronize two config files. Have a nice Monday! Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
Hey, I don't want to pick a side in the turnstile-or-not fight, so I found something you seemed to agree on, to disagree with: Paul Sopka schrob: > > [...] and unless you want to make users replace their shell with > > something like `/etc/execline-startup` as described in > > https://skarnet.org/lists/supervision/3126.html, your proposal is going > > to need a custom PAM module for that too. > [...] > My proposal [...] > by a potential pam module that exports it's content to the users shell. There's already pam_env to set environment variables. And from pam_env.conf it can expand @{HOME} and presumably ${USER}, which should be all you need to accomodate desktop stuff that expects XDG_* and DBUS_SESSION_BUS_ADDRESS. Everything else can and should be done via conventional places in the file system, the way DJB intended. ;) cheers, Jan signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
I am resending this unsigned, since the message is too large otherwise. - `/run/turnstiled/sessions` exposes similar data as your proposal's `/run/session` folder (including being able to query the session type). Take a closer look at the prior art before writing it off. Thank you for pointing that out. To my defense, this is neither mentioned on the Github page (https://github.com/chimera-linux/turnstile) nor in the manpage. Sorry if I have overlooked something. Anyway this is not what made me start creating this alternative. My main reason is that the way my solution currently handles it, allows: a) for different bundles to be started for different types of logins. b) integrates better with my approach of handling the user service trees with instantiated s6/s6-rc services. c) for less overhead and is way simpler e.g. not having to have a daemon running all the time. - Just the session data isn't enough, as you need to patch third party software that relies on it [3]. Turnstile (or, really, any proposal that doesn't assume a specific setup of the underlying system) allows sharing this load with other distributions. [3]https://github.com/void-linux/void-packages/pull/44676 Those are mostly patches to Turnstile, and changes to files in /etc/pam.d which, as config files, are distribution/system specific anyway. There is one patch that is not about the above is a patch to polikit. I need to investigate whether this is needed for my solution too, since my knowledge about polkit is limited. I still need to test all the greeters, but agetty and ssh work like a charm. On a sidenote: I run everything that I am seriously proposing on my daily system. This includes the proposed session management script. - Expecting the user to directly edit scripts if they want different behavior, instead providing some degree of built-in configurability, is not reasonable for a packaged solution, as even the smallest user tweaks would be in constant attrition with package upgrades. I completely agree, I have stated (twice) that this is a very crude version. I only posted this to see whether there are any fundamental flaws with the idea. The statements about extensibility, e.g. - Possibly create a /run/session/${USER} directory. Were more about what I am considering to add. Of course I will refine the script and add configurability. I am also thinking about turning it into a little PAM module itself to allow it to export environment variables to the user's shell. - Without a daemon's mediation, processes writing to the database have to coordinate themselves with locks¹. This introduces risks and limitations you don't want to have when said writes are happening without human oversight [1] [2]. Turnstile is a daemon for a good reason. [1]https://skarnet.org/software/s6-rc/s6-rc.html (-b option). That's why the option -b is here, the example of nested invocations should not be able to happen here, if I understood correctly. [2]https://skarnet.org/lists/supervision/0391.html Doesn't s6-rc -b perfectly solve that for this situation? If not, why? - I won't repeat myself on why a system that relies on calling the current generation of s6-rc upon receiving events, or processes meant to be running in different contexts sharing the same supervision tree, especially one with only a boot-time environment, are a bad idea. Go ahead and actually explain, please. You will not repeat yourself, since, up until now, you really only stated that you are considering it a bad idea. I've already explained why this is not true unless you want to force the project out of its scope, and how it's an infinitely more accurate description for your proposal. Neither did you actually explain that. Please do. I will go into detail on why I think the opposite is true: If we have a group of maintainers responsible for the s6/s6-rc profile, they need to monitor s6/s6-rc closely. In addition to writing and fixing service scripts that is their job. My proposal, in it's current form, adds 4 additional scripts to that, which is not exactly "out of scope". Relying on Turnstile, which to my standards is tightly integrated, requires quite a few things to be done in "the Turnstile way". I am not saying that the latter is bad! This on the other hand naturally requires synchronization between the Turnstile package and whatever provides the user service tree defaults. Which will result in either the Turnstile package having the same maintainers as the s6/s6-rc profile or at least requiring both maintaining groups to have a good connection. I am not saying that any of this is necessarily bad, but it is causing more expenditure. That said, even if it took a bit more effort to maintain my solution, this could be justified by the expanded functionality of per login type bundles and boot time user services. Instead of reducing scope and relying on a loosely coupled third party solution, you're making
Re: s6/s6-rc policy for Gentoo: user session tracking
Yes - but since you're using s6 anyway, you also have s6-setlock, which features more options than flock. ;) I will happily use s6-setlock! That said, it might be of interest to you, that s6-setlock does not appear here: https://skarnet.org/software/s6/index.html. I wish you a nice week! Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: The logging directory
Besides consistency, putting those below $HOME would also break in NFS setups where $HOME is shared among several machines. Good point. I will keep the user logs at /var/log/s6/user/${USER} for now. Please don't. There's already 2 different standards for dotfiles (XDG and ~/.nameofprogram), inventing a third one is a case of https://xkcd.com/927/ (But per the above, ~/ is not apropriate anyway, so the point is moot.) I am not planning that, don't worry. I am only thinking about the idea. Generally, I think sometimes the 15th standard is needed if the other fourteen are terrible enough. People made the same joke about pipewire when it was started xD. Have a nice week! Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: The logging directory
Hey, Paul Sopka schrob: > [ user services have service dir in /run and logs in /var ] > What do you think about that reasoning? Agree. Besides consistency, putting those below $HOME would also break in NFS setups where $HOME is shared among several machines. > I do not *want* to adhere to the XDG spec, it just seemed sensible to me and > nobody has provided any reason against it so far. See reason above. ;) But otherwise the correct sentiment. > Anyway, [1] made me think about why not to use a "/"-like structure under > "~/" (e.g. ~/.var, ~/.etc) instead of the XDG spec. Can you point me to any > thread/list discussing that? Please don't. There's already 2 different standards for dotfiles (XDG and ~/.nameofprogram), inventing a third one is a case of https://xkcd.com/927/ (But per the above, ~/ is not apropriate anyway, so the point is moot.) cheers, Jan signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
Em qui., 11 de jul. de 2024 às 11:55, Paul Sopka escreveu: > I will try and summarize what we have now. > > I hope you are fine with this. Sure. Long e-mails get tiring to read and reply to, for both of us. > https://skarnet.org/lists/supervision/3139.html Frankly, your priorities when designing a replacement were very misguided. - `/run/turnstiled/sessions` exposes similar data as your proposal's `/run/session` folder (including being able to query the session type). Take a closer look at the prior art before writing it off. - Just the session data isn't enough, as you need to patch third party software that relies on it [3]. Turnstile (or, really, any proposal that doesn't assume a specific setup of the underlying system) allows sharing this load with other distributions. - Without a daemon's mediation, processes writing to the database have to coordinate themselves with locks¹. This introduces risks and limitations you don't want to have when said writes are happening without human oversight [1] [2]. Turnstile is a daemon for a good reason. - Expecting the user to directly edit scripts if they want different behavior, instead providing some degree of built-in configurability, is not reasonable for a packaged solution, as even the smallest user tweaks would be in constant attrition with package upgrades. - I won't repeat myself on why a system that relies on calling the current generation of s6-rc upon receiving events, or processes meant to be running in different contexts sharing the same supervision tree, especially one with only a boot-time environment, are a bad idea. ¹Which are missing from your script entirely, which is dangerous when you have in-place editing such as the counter and newline files. [1] https://skarnet.org/software/s6-rc/s6-rc.html (-b option). [2] https://skarnet.org/lists/supervision/0391.html [3] https://github.com/void-linux/void-packages/pull/44676 > Turnstile > > - Forks the user-tree off the turnstile process, directly related to the > login session. Not to _the_, but to _a_ login session. Whenever turnstiled is informed of a log-in, it loads the PAM modules in /etc/pam.d/turnstiled, and runs `backend run ...` as the shell. You can confirm that with a pstree; dinit/s6-svscan are children of an intermediate "turnstiled" process, not `login`/your display manager (see [1] for why replicating this directly on top of a supervision suite is more trouble than it's worth). [1] https://jdebp.uk/FGA/dont-abuse-su-for-dropping-privileges.html, section "PAM changed everything". > - Needs close monitoring by the people responsible for the s6/s6-rc > overlay/profile or at least good connection between them and the > maintainer of the Turnstile ebuild, due to its tight integration. I've already explained why this is not true unless you want to force the project out of its scope, and how it's an infinitely more accurate description for your proposal. Instead of reducing scope and relying on a loosely coupled third party solution, you're making a solution that marries session tracking to a specific policy for a specific init system. I wonder where I've seen that before. > Did I miss anything important? I believe you're correct on the other points. Since I've made my points here also regarding the "user session tracking" thread, I won't make a standalone reply to it. > Have a nice Thursday! Have a nice Saturday :D
Re: s6/s6-rc policy for Gentoo: user session tracking
Good point. If I understood everything correctly, this can be easily solved by the "flock" command, right? Yes - but since you're using s6 anyway, you also have s6-setlock, which features more options than flock. ;) -- Laurent
Re: s6/s6-rc policy for Gentoo: user session tracking
These two last points, if you really decide to implement them like that in the final version, may require some synchronization, e.g. via file locking. It is not impossible (I mean, it is quite unlikely, but especially with automated CI systems not impossible *at all*) for two SSH sessions to come in practically at once, and I have indeed seen shell startup scripts run the same program at the same time. Good point. If I understood everything correctly, this can be easily solved by the "flock" command, right? It would be... interesting to have one login session write the first line, then another session immediately write the second one, and then neither of them will find exactly one line in the file 🙂 And same for logout. Indeed. Have a nice weekend! Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: The logging directory
On my setup, logs are stored under a dot-directory in my home directory, which avoids needing any cooperation from root when setting up user services (and the mentioned risk of overlap between user and system services). Since I have a system service setting up the user service tree, this is a non-issue for me. As of now, this service just creates a user owned subdir /var/log/s6/user/${USER}, where all logs from ${USER} go. Thus the main thing probably ends up weighing "having all logs at one place"(at /var/log/s6) against "having all user-stuff as well as the logs in one place" (at ~/). If I now compare this to ${XDG_RUNTIME_DIR} and the service dir of the s6 user-tree, it follows that, should I have the logs at "~/...", why do I have "${XDG_RUNTIME_DIR} as well as the service dir of the user" at /run/... It is clear that those should reside in tmpfs for speed and the elegance of self clean up on boot, should something go wrong. I would consider mounting an tmpfs for every user having set up user-services at "~/" needlessly complicated and overkill. For consistency reasons it then follows that the user tree logs should be in a dir at /var/log/s6/users/${USER} or something comparable, as the "${XDG_RUNTIME_DIR} and service dir of the user" are at /run/user/${USER} or comparable. With the nice bonus of having all the logs in one place. What do you think about that reasoning? Due to /var == ~/.local/state according to the XDG spec (which, from your other threads, you seem to want to follow closely), you might want to use "${HOME}/.local/state/log/${daemon}" [1]. I do not *want* to adhere to the XDG spec, it just seemed sensible to me and nobody has provided any reason against it so far. Anyway, [1] made me think about why not to use a "/"-like structure under "~/" (e.g. ~/.var, ~/.etc) instead of the XDG spec. Can you point me to any thread/list discussing that? [1]https://forum.artixlinux.org/index.php/topic,6918.msg41919.html#msg41919 I wish you a very nice weekend! Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: user session tracking
On Thu, Jul 11, 2024 at 04:53:51PM +0200, Paul Sopka wrote: > Since I was not 100% convinced by Turnstile, I made an attempt on a very > simple alternative way to handle user session tracking. > > The (currently very crude) script only runs once on each login and logout > and does the following: > > On login: > > - Possibly create a /run/session/${USER} directory. > > - Possibly start the user supervision tree (from S6/s6-rc or OpenRC, or > anything but itself). > > - If it does not exist, create a file named after the login type (e.g. sshd) > at /run/session/${USER}/${LOGIN_TYPE}. > > - Write a line (any content, but just one line) to > /run/session/${USER}/${LOGIN_TYPE}. > > - If the line count in /run/session/${USER}/${LOGIN_TYPE} is 1, start the > bundle corresponding to ${LOGIN_TYPE} e.g. sshd. These two last points, if you really decide to implement them like that in the final version, may require some synchronization, e.g. via file locking. It is not impossible (I mean, it is quite unlikely, but especially with automated CI systems not impossible *at all*) for two SSH sessions to come in practically at once, and I have indeed seen shell startup scripts run the same program at the same time. It would be... interesting to have one login session write the first line, then another session immediately write the second one, and then neither of them will find exactly one line in the file :) And same for logout. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: The logging directory
On my setup, logs are stored under a dot-directory in my home directory, which avoids needing any cooperation from root when setting up user services (and the mentioned risk of overlap between user and system services). Due to /var == ~/.local/state according to the XDG spec (which, from your other threads, you seem to want to follow closely), you might want to use "${HOME}/.local/state/log/${daemon}" [1]. [1] https://forum.artixlinux.org/index.php/topic,6918.msg41919.html#msg41919 Em ter., 9 de jul. de 2024 às 05:24, Paul Sopka escreveu: > > > Quick question (that you may have already thought about, apologies in > > advance): what happens if one wants to start a new daemon that has > > the same name as an already existing system user account? > > Also, what happens if a new system user account is created with > > the same name as an already configured service daemon? > Thank you for the heads up and don't apologize, you are completely right. > > Indeed. Those should be /var/log/s6/${daemon} and > > /var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on > > any toes. > > This seems sensible, but I will think a bit more about the exact naming. > > > Paul >
Re: s6/s6-rc policy for Gentoo: logging settings
Should every s6-log daemon have it's own config file or shall they all share one? What kind of stuff are you putting in the config file? Is it just a template for a logging script? Is there any general issue with the global env's from s6-linux-init's env directory, which makes sourcing the same config file in every s6-log script a better choice for a global config? The global environment defined in s6-linux-init applies to *all* processes in the system. It's not nice to pollute it with stuff that would only apply to a pretty restricted subset of all the processes on the machine. Source your config file in every logger run script you have, and leave the global environment alone. There will be no performance issue. For more configurability, you could e.g. have a default logging template hardcoded in your run scripts, that you could override via a service- specific configuration file. -- Laurent
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
Thanks for the extensive answer. Since I feel like we are more and more fighting about each others wording and the answers consisting of quotations of each other get longer and longer, I will try and summarize what we have now. I hope you are fine with this. My approach(see here: https://skarnet.org/lists/supervision/3139.html): - Forks the user-tree off the system-tree. - Allows autostart of different bundles at different times (e.g. directly at boot time) / login types (e.g. on ssh login, on graphical login, ...). - I still need to find/decide on a good solution for getting the env's to the user's shell. - Needs direct maintenance of the people responsible for the s6/s6-rc overlay/profile. - Adds the need for ~3 (when using s6-rc) system services to properly handle user service tree creation and instantiation. Turnstile - Forks the user-tree off the turnstile process, directly related to the login session. - Austostarts the same user services on every login type, none on boot. - Automatically exports env's to the user's shell. - Needs close monitoring by the people responsible for the s6/s6-rc overlay/profile or at least good connection between them and the maintainer of the Turnstile ebuild, due to its tight integration. - Handles user service tree creation itself. Did I miss anything important? Anyway, I will happily to continue this discussion, I think someone criticizing my ideas as strongly as you do, is the best way to bring their issues and flaws to light, so that I can solve them or even realize that I am on the wrong track alltogether. Obarun Linux's 66 service manager (which is the one mentioned in the closed Turnstile issue you first commented on) also works with s6 user supervision trees spawned directly off of the system tree. You might want to study it. Thank you, I will look into that! ...and you're probably tired of me shilling Turnstile :P. No, not at all, I have learned a lot from your criticisms. Seriously, keep going! Have a nice Thursday! OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
Em seg., 8 de jul. de 2024 às 09:55, Paul Sopka escreveu: > You're making more work for yourself and the people who'd help you > maintain the service set, and making an s6 policy with more > assumptions. > > I disagree. If the most important work is delegated to the service scripts, once it works, it works. Forever. Easy to adapt and replace by sysadmins/users. "Forever" is a strong word (see below), and for the latter of these to be true, a lot of thought must go into packaging and design. > Extremely relying on specific functionality of an external program, forces the maintainer to tightly monitor the programs development and extensively test all its releases. This is the maintainer's job. Even s6 is not an unchanging foundation; it has had commands being renamed and shifting from one package to another in the past, and some use cases stopped being supported along the way. One example I remember is setsid becoming mandatory for services, which broke mine and a few people's "X server/compositor as a service" setup under elogind+polkit back in the day. > in practice: forcing the possible Turnstile package on Gentoo to have the same maintainer(maintaining group) as the possible s6/s6-rc profile. Not necessarily. Turnstile is designed in a way that makes it possible for the people writing the s6-rc profile to focus on getting system daemons right and have their mission regarding desktop services stop at creating a Turnstile service, and to ensure the responsibility for a working user services setup to fall entirely on the maintainers of latter, which can test every backend without switching PID 1 – people from other profiles could help test it (as is the case in Artix; there are OpenRC users who use Turnstile despite there being only runit and dinit backends). Turnstile's developers also seem to be cooperative in regards to having backends upstreamed and coordinating changes to them. Instead, your proposals heavily burden the s6/s6-rc profile developers with a mostly desktop-specific problem, task them with developing and maintaining not only a complex and specialized set of services but also custom PAM modules, and the result relies heavily on using s6-rc with dynamic event sources, which it is not yet perfectly suited for. > It also forces more assumptions on everybody, since we need to comply to the exact way Turnstile solves things: > Non daemontools-style supervisors, such as dinit (which is Turnstile's > default), also don't provide a simple "setuidgid" privilege dropper, > so they'll have little use for this functionality unless they add more > dependencies or become more error-prone. > > This shows it quite nice, as it would have me need to align more to the limitations of dinit, even though I do have the tools for the job. The limitation is not because of dinit. It's part of the project's goals. (If they really wanted to, they could clone setuidgid, as many people have since daemontools came out, or accept the risk that comes with root privileges). The s6-rc backend you're requesting in that issue would be a special snowflake that ignores the XDG_RUNTIME_DIR setting present in turnstiled.conf in favor of one in a idiosyncratic master environment file instead, and assumes a specific system service manager with a specific set of services (most of which duplicating what Turnstile already provides). Remember Turnstile backends should not care about what PID 1 is running. There are only multiple config files to worry about keeping in sync, and unavoidable integration issues that require constant intervention from the maintainers of the s6 system service set, because you want to force the project in a different role from what it was designed for: a one stop shop desktop service daemon. Since you're bumping against core design decisions in Turnstile, your setup is better off relying on its own PAM stuff. > There's two additional arguments: "$srv_dir", a folder that's > dedicated to temporary files for the service manager (which seems to > me to be the ideal place for s6-svscan's scan directory and s6-rc's > live folder¹), and "$confdir", which is the path to where the > configuration files reside (which can serve as the storage place for > an environment file). > > It seems less then ideal to me to use the filesystem as a temporary storage, when all that is needed are a handful environmental variables, which can easily be passed to the backend. I'm not sure what environment variables you are referring to. If you mean storing XDG_RUNTIME_DIR and s6-rc's live directory there for the ready directive, see below for why I don't think it's a good idea. > Given dinit has the service management and service supervision layers > in the same executable, Turnstile's authors probably expect the > service management layer being up and running by the time 'run' has > notified readiness, which is possibly why they didn't bother exporting > variables in the "ready" script. > > Adding the ability to pass th
Re: s6/s6-rc policy for Gentoo: The logging directory
Quick question (that you may have already thought about, apologies in advance): what happens if one wants to start a new daemon that has the same name as an already existing system user account? Also, what happens if a new system user account is created with the same name as an already configured service daemon? Thank you for the heads up and don't apologize, you are completely right. Indeed. Those should be /var/log/s6/${daemon} and /var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on any toes. This seems sensible, but I will think a bit more about the exact naming. Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: The logging directory
Peter Pentchev schrob: > On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote: > > System supervision tree logs to to /var/log/${daemon} > > > > User supervision tree logs got to /var/log/${USER}/${daemon} > > Quick question (that you may have already thought about, apologies in > advance): what happens if one wants to start a new daemon that has > the same name as an already existing system user account? > Also, what happens if a new system user account is created with > the same name as an already configured service daemon? Indeed. Those should be /var/log/s6/${daemon} and /var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on any toes. signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: The logging directory
On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote: > The last "thread" I open for this night. I promise. > > I currently have set up logging in the following way: > > System supervision tree logs to to /var/log/${daemon} > > User supervision tree logs got to /var/log/${USER}/${daemon} Quick question (that you may have already thought about, apologies in advance): what happens if one wants to start a new daemon that has the same name as an already existing system user account? Also, what happens if a new system user account is created with the same name as an already configured service daemon? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo
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 defaulting to "if $concurrent == 0 then s6-rc start $type" ~/.foo/logout defaulting to "if $concurrent == 0 then s6-rc stop $type" Amazing, thank you, I will look into that as soon as I can! Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
You're making more work for yourself and the people who'd help you maintain the service set, and making an s6 policy with more assumptions. I disagree. If the most important work is delegated to the service scripts, once it works, it works. Forever. Easy to adapt and replace by sysadmins/users. Extremely relying on specific functionality of an external program, forces the maintainer to tightly monitor the programs development and extensively test all its releases, in practice: forcing the possible Turnstile package on Gentoo to have the same maintainer(maintaining group) as the possible s6/s6-rc profile. It also forces more assumptions on everybody, since we need to comply to the exact way Turnstile solves things: Non daemontools-style supervisors, such as dinit (which is Turnstile's default), also don't provide a simple "setuidgid" privilege dropper, so they'll have little use for this functionality unless they add more dependencies or become more error-prone. This shows it quite nice, as it would have me need to align more to the limitations of dinit, even though I do have the tools for the job. Running the backend as root could just be added as a config option to Turnstile. But I think we are approaching philosophical/subjective grounds here. It is good that we develop our own interpretations of "the best" solution, learning from and criticizing each other. There's two additional arguments: "$srv_dir", a folder that's dedicated to temporary files for the service manager (which seems to me to be the ideal place for s6-svscan's scan directory and s6-rc's live folder¹), and "$confdir", which is the path to where the configuration files reside (which can serve as the storage place for an environment file). It seems less then ideal to me to use the filesystem as a temporary storage, when all that is needed are a handful environmental variables, which can easily be passed to the backend. See `/run/service/s6rc-fdholder-filler/run` on your machine for another solution: have 'ready' be only ``` s6-rc -l "$string" -up change default ``` and 'run' be ``` ... fdmove -c 3 1 pipeline -dw { if -nt { s6-rc-init } s6-svscanctl -t ... } fdswap 3 1 s6-svscan -d3 ... ``` Instead of just s6-svscan (i. e. feed the readiness notification to another step instead directly sending s6-svscan's notification to turnstile). Thanks, will test! Given dinit has the service management and service supervision layers in the same executable, Turnstile's authors probably expect the service management layer being up and running by the time 'run' has notified readiness, which is possibly why they didn't bother exporting variables in the "ready" script. Adding the ability to pass the env's to the ready function in the form of a config option in turnstile.conf would probably be the best way to allow elegant integration with s6-rc. I have opened an issue for that, see here: https://github.com/chimera-linux/turnstile/issues/15 Turnstile already answers item b: `/etc/turnstile/backend/*.conf` and argument #4 of the run script. For a, nothing stops a backend from sourcing one itself, and the runit backend is a precedent. Yet again needing tight integration with Turnstile. I do not think this is inherently bad, I just do not personally like such tight integration if I can do it differently. I'd rather document that the user must edit the desktop service daemon's settings if they want to tweak how desktop services work. I technically agree, but some configs must be global, e.g. ${DBUS_SESSION_BUS_ADDRESS}, since other services, e.g. Pipewire, rely on them. The alternative would be a dynamically populated and sourced env directory, I am still thinking about this, but the issue I see is how to propagate the required (currently ${DBUS_SESSION_BUS_ADDRESS} and ${XDG_RUNTIME_DIR}) to the user's login shell now that they are dynamic and maybe not completely set on login? For instance, I once tried to make my equivalent set of scripts "username-agnostic" and use s6's (the supervision suite's) built-in instancing feature — with the username as the parameter — to spawn user supervision trees. This was enough to make execline painful to use correctly, and I had to switch to a shell script. I will try that too, because I think this would be the most elegant way to start user service trees, if one doesn't want to rely on Turnstile. I'm currently writing a turnstile backend [1] that has a catch-all logger and does s6-rc-init in the `run` step; it's refreshing to be able to reasonably write it in execline. [1]https://paste.artixlinux.org/view/6308e776 Wow, I will look into that in more detail for sure! I don't think "low number of config files" is a metric worth optimizing for, especially when the tradeoff is encoding desktop assumptions in low-level policy. I need to be careful to not have two or more important config files that contain the same setting parsed by different essential sof
Re: s6/s6-rc policy for Gentoo
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 defaulting to "if $concurrent == 0 then s6-rc start $type" ~/.foo/logout 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 signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo
Replacing crond with snooze, for example. And personally, I want my ssh-agent to stay alive when I log out, so that the key is still unlocked if/when I immediately log in again. You have convinced me, I will see whether it is feasible to have a *third* user-service tree. I fear I just have to bite the bullet and decide upon one or two options or at least let the sysadmin decide. Yet another reason to not integrate extremely tight into Turnstile and similar, which would disallow this flexibility. 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? 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. Ugh. I hate this thinking. Server/Desktop is not a binary choice. I regularly ssh into otheruser@localhost on my main machine. Sometimes I log in as otheruser and startx. Occasionally I start a vnc server as otheruser. I have an mpd instance that runs as its own user. Any desktop-only solution where people argue "you shouldn't do this on a server" is one where I'll argue "you shouldn't do this at all". It looks like I just do not have enough experience, that's why I am asking you all on those points. You are right. 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. * create a unique live dir from the "graphical" template * start compositor ** in compositor's autostart, have something that exports the WAYLAND_DISPLAY and calls s6-rc start ** (if possible) register s6-rc stop as an exit hook with compositor * once the compositor exits, tear down everything. Yes, I have suggested this too, the issues is not the starting part, but the proper stopping of the services. This can only be guaranteed if the compositor sends SIGTERM to s6-svscan upon exiting. I still need to test that, but to not have to rely on the compositor doing that correctly is why I have proposed hooking into seatd in the first place. The finish script of the s6-svscan should then handle cleanup just fine. Or just use X11, which properly separates Xserver from WM, avoiding any problems caused by uncooperative compositors. I am planning to support an entire distro, thus I need to support them all: well behaved compositors, badly behaved compositors, X11, ... If it needs a display, it goes into C, otherwise into B. I guess writing this into a wiki article mandatory for user services anyway would be good enough. Feasible, sure. Good idea, probably not. A misconfigured compositor restarting over and over again is a pain to fix. Agreed. PAM. Assuming you use PAM to create the XDG_RUNTIME_DIR and start the dbus. Using PAM for propagating the env's seems reasonable, since we are using it already anyway. Will test. On a sidenote, I still think creating XDG_RUNTIME_DIR should be the job of the system-service managing the user tree. Thank you for your input! Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo
Paul Sopka schrob: > My claim was more about a practical, applied scenario. In the terms of: If a > user is not logged in, he simply cannot control his services. So why shall > he have an entire user supervision tree of which the sole purpose is to > allow the user to control the services running with his permission set, > running at a time he is not logged in, thus not able to control his > services? That part seems confused. The user is able to control their services by logging in and then invoking s6-whatever. > Do you see any cases where this would actually be useful in real world > applications? Replacing crond with snooze, for example. And personally, I want my ssh-agent to stay alive when I log out, so that the key is still unlocked if/when I immediately log in again. > Concerning your last point, the best I can offer for now is to have a > script, using a template dir to create the user supervision system service. > This can of course only be done by the system admin. The user can then add > whatever he wants to a previously empty bundle described in the wiki, before > invoking an "s6-user-db-update" command or similar, invoking a script that I > supply and that does the compilation and s6-rc-update command. 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)? > on a desktop system you rarely have someone ssh'ing in. > On a server system no user will ever add heavy desktop scripts to the user > service autostart, because a) he can't use them anyway and b) they shouldn't > be there(why the heck should the sysadmin install e.g. pipewire or mpd on > such a server? Packages which would be responsible for drawing in the > required user services.) Ugh. I hate this thinking. Server/Desktop is not a binary choice. I regularly ssh into otheruser@localhost on my main machine. Sometimes I log in as otheruser and startx. Occasionally I start a vnc server as otheruser. I have an mpd instance that runs as its own user. Any desktop-only solution where people argue "you shouldn't do this on a server" is one where I'll argue "you shouldn't do this at all". > [...] > And by "up and running" I mean WAYLAND_DISPLAY is set by the compositor. > > I would not call the foot terminal emulator unrelated to WAYLAND_DISPLAY and > the compositor at all. > > But I argue that, in case it is ran in it's server configuration, it makes > sense to supervise it, i.e. not starting it directly from the compositor. > The same can be said about notification daemons, status bars, ... You can supervise it, but the supervision tree is dependent on the compositor. If the compositor goes away, the supervision tree needs to die as well. If you start two compositors, you need to create two supervision trees, one for each WAYLAND_DISPLAY. > As you have already said this is the best example for why an additional C) > would make sense. This is where my next problem arises, imagine we now set > up another supervision tree for starting it up as soon as the compositor is > there. > > I can probably cleanly do this my reading from the socket seatd provides and > using s6-fdholder-retrieve, right? How could this be stopped cleanly upon > exiting the wayland compositor? > > The issue on how to retrieve WAYLAND_DISPLAY arises again. > > This could be solved by starting the "graphical" s6-svscan from the > compositor, e.g. Hyprland, even though the compositor is not supervised, > once it crashes it takes everything depending on it down with it anyway, so > this doesn't matter. The biggest issue is, yet again, how to stop the > services cleanly on exiting the compositor. Any ideas? * create a unique live dir from the "graphical" template * start compositor ** in compositor's autostart, have something that exports the WAYLAND_DISPLAY and calls s6-rc start ** (if possible) register s6-rc stop as an exit hook with compositor * once the compositor exits, tear down everything. Or just use X11, which properly separates Xserver from WM, avoiding any problems caused by uncooperative compositors. > Another issue I see is that the user of the desktop system gets a third > supervision tree he has to manage. And for most of the more casual people it > is probably hard to correctly understand and use the differences between C) > and B), in the little free time they can invest into linux. If it needs a display, it goes into C, otherwise into B. > There is another alternative I see: starting the compositor itself as a user > service. I have to think about how feasible this is. What do you think? Feasible, sure. Good idea, probably not. A misconfigured compositor restarting over and over again is a pain to fix. > This brings me to the final problem which the alternative mentioned above > solves already: The user services manage a couple of things, namely the > XDG_RUNTIME_DIR and DBUS_SESSION_BUS_A
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
Em dom., 7 de jul. de 2024 às 06:06, Paul Sopka escreveu: > Instead, I want to delegate as few functionality to them as possible. Why > should I e.g. delegate the creation a directory to a binary, configured > through its own config file, if it would just be one line in a script that > loads the defining variables and is ran anyway? Because, as you noticed, this will require root privileges in the backend. And, to make it generic, complexity will again be shifted into the service set; the common default "/run/user/${UID}", for instance, implies serial substitution in an execline script [1] or eval in a shell. Which by then, it will no longer be a matter of "just 2 lines of execline". [1] See https://skarnet.org/software/execline/multisubstitute.html ("Security" section) https://skarnet.org/lists/skaware/2049.html. Non daemontools-style supervisors, such as dinit (which is Turnstile's default), also don't provide a simple "setuidgid" privilege dropper, so they'll have little use for this functionality unless they add more dependencies or become more error-prone. You're making more work for yourself and the people who'd help you maintain the service set, and making an s6 policy with more assumptions. > > I experimented with Turnstile yesterday and hit major roadblocks. > > Here is what I have understood it does: > > once the user first logs in: > > a1) execute "${BACKEND} run ${notification_fd}"with an environment of > ${USER}, ${HOME}, ... There's two additional arguments: "$srv_dir", a folder that's dedicated to temporary files for the service manager (which seems to me to be the ideal place for s6-svscan's scan directory and s6-rc's live folder¹), and "$confdir", which is the path to where the configuration files reside (which can serve as the storage place for an environment file). ¹From my testing, XDG_RUNTIME_DIR also works. > This does not work, since when a2) is invoked to run the "ready" part, we do > not have ${XDG_RUNTIME_DIR} anymore. I do not see how to solve this without a > workaround. > > A possible workaround would be doubly defining XDG_RUNTIME_DIR, once in the > Turnstile config and once in an env file which is sourced in the "ready" > "function". > See `/run/service/s6rc-fdholder-filler/run` on your machine for another solution: have 'ready' be only ``` s6-rc -l "$string" -up change default ``` and 'run' be ``` ... fdmove -c 3 1 pipeline -dw { if -nt { s6-rc-init } s6-svscanctl -t ... } fdswap 3 1 s6-svscan -d3 ... ``` Instead of just s6-svscan (i. e. feed the readiness notification to another step instead directly sending s6-svscan's notification to turnstile). Given dinit has the service management and service supervision layers in the same executable, Turnstile's authors probably expect the service management layer being up and running by the time 'run' has notified readiness, which is possibly why they didn't bother exporting variables in the "ready" script. > > I have two major issues here: > > A) ${BACKEND} is always invoked with the user's privileges, thus it can not > create ${XDG_RUNTIME_DIR} itself. > > B) a2) happens without the environment, see the issue with the script. > > > I think A) is a problem, since I am planning: > > a) to have a central user env file, preferably at > /home/${USER}/.config/s6-env (${XDG_CONFIG_HOME}/s6-env), for the user to > tweak his settings, e.g. ${DBUS_SESSION_BUS_ADDRESS} > > > b) to have a central sysadmin env file, preferably at /etc/s6-rc/config (or > similar), for the system admin to tweak the settings, e.g. the > ${XDG_RUNTIME_DIR} general structure, the creation of which has to be > delegated to Turnstile, since the script does not have enough permissions. > This would then have to be doubly defined(once in the Turnstile config and > once in the env-file) > Turnstile already answers item b: `/etc/turnstile/backend/*.conf` and argument #4 of the run script. For a, nothing stops a backend from sourcing one itself, and the runit backend is a precedent. I'd rather document that the user must edit the desktop service daemon's settings if they want to tweak how desktop services work. > > Saying "this will make it easier to implement an alternative" > overlooks the fact that the complexity will be shifted into the > service set and the service manager. Is it really worth it to go > through dynamic services and events (at least, one `install -d` > oneshot per user, and a first login/last logout event source), and > probably other things required to make this more reliable, pretty much > just to make a folder? > > I agree about the complexity shift. But I think the solution of using > Turnstile just as a "notifications-system" is the best: ideally it should do > the following: if ${USER} first logs in, start the system service ${USER}, if > he logs out of the last instance stop the system service ${USER}. > > This yields the following advantages: > > A) The added complexity is in my opinion negligible(see
Re: s6/s6-rc policy for Gentoo
What I do is little different: my login shell is /etc/execline-startup, which after setting up a few things, execs into ~/.execline-loginshell, which among other things execs into s6-envdir reading the same env dir as my supervision tree, and finally executes into my actual shell. I’ll attach the files to this email so you can take a look at them. This looks sensible, I might use this for myself. That said, I have come to the following conclusion: Gentoo is a distribution based on choice and freedom of configuration. Thus I will probably just add a section to the user-service wiki entry I will write, explaining what directory has to be sourced and why as well as providing examples on how to do this with the most common login methods. Thank you! Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo: The logging directory
foreground install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} "" foreground install -d -o ${USER} -g ${USER} /var/log/${USER} "" foreground install -d -o ${USER} -g ${USER} ${XDG_RUNTIME_DIR}/service "" foreground { install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} } foreground { install -d -o ${USER} -g ${USER} /var/log/${USER} } foreground { install -d -o ${USER} -g ${USER} ${XDG_RUNTIME_DIR}/service } This seems more idiomatic to me. Agreed, will change. Thank you! Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo
Hi, Am Sa, Jul 06, 2024 am 03:09:26 +0200 schrieb Paul Sopka: This brings me to the final problem which the alternative mentioned above solves already: The user services manage a couple of things, namely the XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS that need to be propagated to the users login shell. Is there a more elegant way to do this other then having the user source an env directory in his .bash_profile? What I do is little different: my login shell is /etc/execline-startup, which after setting up a few things, execs into ~/.execline-loginshell, which among other things execs into s6-envdir reading the same env dir as my supervision tree, and finally executes into my actual shell. I’ll attach the files to this email so you can take a look at them. Don’t credit me on this, I actually took it all from the lh-bootstrap stuff written by Laurent. :D BISOUS Hoël #!/bin/execlineb -s0 /bin/multisubstitute { importas -i HOME HOME importas -i LOGNAME LOGNAME } /bin/export USER ${LOGNAME} /bin/s6-envdir /etc/env-startup /bin/fdblock 0 /bin/fdblock 1 /bin/fdblock 2 /bin/tryexec { ${HOME}/.execline-loginshell $@ } /etc/execline-shell $@ #!/bin/execlineb -s0 importas -i PATH PATH importas -i HOME HOME export PATH ${HOME}/.local/bin:${PATH} s6-envdir ${HOME}/.config/env ${HOME}/.execline-shell $@ #!/bin/execlineb -s0 backtick -nx GPG_TTY { tty } fish $@ signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
I don't think avoiding Turnstile (and similar projects) in favor of s6 services is reasonable, given the concerns you've raised in the first block ofhttps://skarnet.org/lists/supervision/3122.html (especially "I'd like for the user supervision tree to only start on-demand"). I do not want to avoid them, they are straight up required to setup option B) from https://skarnet.org/lists/supervision/3114.html. Instead, I want to delegate as few functionality to them as possible. Why should I e.g. delegate the creation a directory to a binary, configured through its own config file, if it would just be one line in a script that loads the defining variables and is ran anyway? Turnstile's interface is reasonably simple and easy to implement in an alternative: backends are effectively supervised 'run' (in the s6/runit sense) scripts for the service manager with extra arguments, and I believe it to be pretty much the minimum viable program for adding XDG_RUNTIME_DIR compliance to any given service manager. I experimented with Turnstile yesterday and hit major roadblocks. Here is what I have understood it does: once the user first logs in: a1) execute "${BACKEND} run ${notification_fd}" with an environment of ${USER}, ${HOME}, ... once ${BACKEND} writes back to ${notification_fd}: a2) execute "${BACKEND} ready ${string}"/ without /the environment, but passing what was written back to ${notification_fd} beforehand as ${string} once the user last logs out: b1) execute "${BACKEND} stop" b2) kill the process started in a1) (in our case s6-svscan) From that structure I naturally would propose the following script, having ${XDG_RUNTIME_DIR} managed by Turnstile: #!/usr/bin/env execlineb importas directive 1 importas readinessPipe 2 importas -S XDG_RUNTIME_DIR importas -S USER case ${directive} { run { foreground { install -d -o ${USER} -g ${USER} ${XDG_RUNTIME_DIR}/service } redirfd -w 3 ${readinessPipe} s6-svscan -d3 ${XDG_RUNTIME_DIR}/service } ready { foreground { s6-rc-init -c /home/${USER}/.local/share/s6-rc/compiled -l ${XDG_RUNTIME_DIR}/s6-rc ${XDG_RUNTIME_DIR}/service } s6-rc -v2 -l ${XDG_RUNTIME_DIR}/s6-rc -up change default } stop { s6-rc -l ${XDG_RUNTIME_DIR}/s6-rc -bDa change } } exit 100 This does not work, since when a2) is invoked to run the "ready" part, we do not have ${XDG_RUNTIME_DIR} anymore. I do not see how to solve this without a workaround. A possible workaround would be doubly defining XDG_RUNTIME_DIR, once in the Turnstile config and once in an env file which is sourced in the "ready" "function". I have two major issues here: A) ${BACKEND} is always invoked with the user's privileges, thus it can not create ${XDG_RUNTIME_DIR} itself. B) a2) happens without the environment, see the issue with the script. I think A) is a problem, since I am planning: a) to have a central user env file, preferably at /home/${USER}/.config/s6-env (${XDG_CONFIG_HOME}/s6-env), for the user to tweak his settings, e.g. ${DBUS_SESSION_BUS_ADDRESS} b) to have a central sysadmin env file, preferably at /etc/s6-rc/config (or similar), for the system admin to tweak the settings, e.g. the ${XDG_RUNTIME_DIR} general structure, the creation of which has to be delegated to Turnstile, since the script does not have enough permissions. This would then have to be doubly defined(once in the Turnstile config and once in the env-file) Saying "this will make it easier to implement an alternative" overlooks the fact that the complexity will be shifted into the service set and the service manager. Is it really worth it to go through dynamic services and events (at least, one `install -d` oneshot per user, and a first login/last logout event source), and probably other things required to make this more reliable, pretty much just to make a folder? I agree about the complexity shift. But I think the solution of using Turnstile just as a "notifications-system" is the best: ideally it should do the following: if ${USER} first logs in, start the system service ${USER}, if he logs out of the last instance stop the system service ${USER}. This yields the following advantages: A) The added complexity is in my opinion negligible(see my current scripts here: https://skarnet.org/lists/supervision/3123.html). B) My idea gives the sysadmin and the user more control over their system (e.g. basing the location of ${XDG_RUNTIME_DIR} on a central env file where other settings are set too). C) My idea allows plugging the user supervision tree directly into the system supervision tree, with the following advantages 1) Allowing to directly attach a "catch all" logger separated from the logger of Turnstile 2) Keeping the chain of efficient and reliable "skarware" from the top of the tree until the last user service, without Turnstile in betwe
Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
I don't think avoiding Turnstile (and similar projects) in favor of s6 services is reasonable, given the concerns you've raised in the first block of https://skarnet.org/lists/supervision/3122.html (especially "I'd like for the user supervision tree to only start on-demand"). Turnstile's interface is reasonably simple and easy to implement in an alternative: backends are effectively supervised 'run' (in the s6/runit sense) scripts for the service manager with extra arguments, and I believe it to be pretty much the minimum viable program for adding XDG_RUNTIME_DIR compliance to any given service manager. Saying "this will make it easier to implement an alternative" overlooks the fact that the complexity will be shifted into the service set and the service manager. Is it really worth it to go through dynamic services and events (at least, one `install -d` oneshot per user, and a first login/last logout event source), and probably other things required to make this more reliable, pretty much just to make a folder? I believe point 3 to be moot because XDG policies are very thorough and doing something even mildly different usually requires redoing everything from scratch. Em sex., 5 de jul. de 2024 às 20:35, Paul Sopka escreveu: > > To keep all the stuff a bit organized, I will open another "thread" for > this. > > I have read through > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > and to me the standards seem sensible. Most of it is the default of most > if not all modern desktop programs anyway. > > Therefore I would like to completely comply with them in this policy. > This involves, but is not limited to, putting the live dir in > XDG_RUNTIME_DIR. Bercot warned me in > https://skarnet.org/lists/supervision/3114.html that this might be > dangerous since it could be removed to quickly upon logout. > > From the start on, I planned to have all the XDG_* env's managed by the > s6-rc system service which sets up the user supervision tree. This means > setting the env's and, in the case of XDG_RUNTIME_DIR, creating and > removing the directory on demand. By implementing this directly in the > service with correct dependencies, this becomes completely safe and > reliable. > > Another suggestion was to delegate the creation and removal of > XDG_RUNTIME_DIR to the login monitoring program (which will most likely > be Turnstile), see https://skarnet.org/lists/supervision/3117.html. I do > not think this is the best idea. Instead, I want to push as much basic > functionality as possible to the s6/s6-rc services, for the following > reasons: > > 1) s6/s6-rc is simple, fast and reliable > > 2) this allows for an easier future substitution of external programs > used (e.g. substituting Turnstile for an alternative) > > 3) This allows for more fine grained control by the > sysadmins/distribution contributors. > > 4) The service setting up and supervising the user tree is perfectly > suited for this, my current, working implementation of creating and > deleting XDG_RUNTIME_DIR containing the live dir consists of two lines > of execline > > > Do you all have any objections/see any issues with the XDG Base > Directory Specification and adhering to them? > > Do you see any issues with my idea of how to handle the XDG_RUNTIME_DIR? > > Any input is welcome! > > > Paul >
Re: s6/s6-rc policy for Gentoo: The logging directory
Any environment variable you want to make available for a whole supervision tree should be added via a "-e var=value" option to your s6-linux-init-maker invocation. Thanks, will do! For user supervision trees, I suppose you're not using s6-l-i-m, so the best place would be to put the variables in an envdir and use "-E $envdir" (and possibly "-e $var" if you need to substitute $USER or something) in your s6-usertree-maker invocation. If you're not using these tools, the best way is to do the same thing they do: put the variables in an envdir somewhere, and source the envdir both before running s6-svscan and before running your s6-rc-init and s6-rc script. I tested s6-usertree-maker, but I does not do everything I need. Anyway, I based my currently working scripts on its output. This is how it looks right now: ${USER}-sv/run: #!/bin/execlineb -P fdmove -c 2 1 define USER Nanderty define XDG_RUNTIME_DIR /run/${USER} emptyenv -p export USER ${USER} s6-envuidgid -i ${USER} backtick -in HOME { homeof ${USER} } multisubstitute { importas -Si USER importas -Si HOME importas -Si UID importas -Si GID importas -Si GIDLIST } foreground install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} "" foreground install -d -o ${USER} -g ${USER} /var/log/${USER} "" foreground install -d -o ${USER} -g ${USER} ${XDG_RUNTIME_DIR}/service "" export XDG_DATA_HOME ${HOME}/.local/share export XDG_STATE_HOME ${HOME}/.local/state export XDG_CACHE_HOME ${HOME}/.cache export XDG_RUNTIME_DIR ${XDG_RUNTIME_DIR} export DBUS_SESSION_BUS_ADDRESS unix:path=${XDG_RUNTIME_DIR}/session-bus s6-applyuidgid -U s6-svscan -d3 ${XDG_RUNTIME_DIR}/service ${USER}-sv/finish: #!/bin/execlineb -P define USER Nanderty rm -rf /run/${USER} ${USER}-rc/up: #!/bin/execlineb -P fdmove -c 2 1 define USER Nanderty s6-setuidgid ${USER} foreground { s6-rc-init -c /home/${USER}/.local/share/s6-rc/compiled -l /run/${USER}/s6-rc /run/${USER}/service } s6-rc -v2 -l /run/${USER}/s6-rc -up change default ${USER}-rc/down: #!/bin/execlineb -P define USER Nanderty s6-setuidgid ${USER} s6-rc -l /run/${USER}/s6-rc -bDa change Plus, of course, the catch all logger for the ${USER}-sv process. I would just export the logging dir variable as I do with the XDG_* vars, so I do not need to source a variable dir. I would need to define them in this script anyway, if I do not want to use the env-dir as a permanent external config file. Would you consider it a better way to utilize an env-dir as a means of a config and source it in ${USER}-sv/run, thus exporting the vars for all child processes anyway? Thank you for your input. Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo
No, because the point is to allow users to have their own services, and you definitely don't want them to have access to the root supervision tree. So you basically have to have a separate subtree for each user (a privilege-dropped s6-svscan), and there are a few more policy questions to answer, in particular how to make sure the users cannot flood the root logs by misconfiguring their own logging system. It's doable, but not quite obvious, and it's also not quite obvious how to set up the system so that you don't spawn a supervision tree for inactive users or users who don't use the feature. So there's a little more work involved. I know what you mean, and technically and in theory I fully agree with you. As mentioned this is my currently running workaround until I implement Turnstile. My claim was more about a practical, applied scenario. In the terms of: If a user is not logged in, he simply cannot control his services. So why shall he have an entire user supervision tree of which the sole purpose is to allow the user to control the services running with his permission set, running at a time he is not logged in, thus not able to control his services? I am sure there are niche cases this solves, but I do not think they are worth the overhead/maintenance burden of adding this on top of B). Do you see any cases where this would actually be useful in real world applications? in particular how to make sure the users cannot flood the root logs by misconfiguring their own logging system. I solved that by simple read/write permissions on on the root log dir, if you mean that. If you are talking about flooding the uncaught logs logger of the system. Is this not just solved by a s6-log service attached to the user s6-svscan, acting as a catch all logger for the user tree. Since this is inherently a system service, the user does not have the power to sabotage this. I am not sure whether I got you right on that. Concerning your last point, the best I can offer for now is to have a script, using a template dir to create the user supervision system service. This can of course only be done by the system admin. The user can then add whatever he wants to a previously empty bundle described in the wiki, before invoking an "s6-user-db-update" command or similar, invoking a script that I supply and that does the compilation and s6-rc-update command. B) shall solve the issue of not spawning needless supervision trees, since it only spawns them upon login. It really depends on your objective. B makes a lot of sense if you want to treat remote logins the same way as seated logins, but there is also an argument to have remote logins be as simple as possible while not minding deploying the red carpet and a whole lot of extra services for seated logins, where the overhead of setting everything up will be negligible compared to the desktop stuff anyway. I, again, technically agree fully, but this is in my opinion already solving itself in practice: on a desktop system you rarely have someone ssh'ing in. On a server system no user will ever add heavy desktop scripts to the user service autostart, because a) he can't use them anyway and b) they shouldn't be there(why the heck should the sysadmin install e.g. pipewire or mpd on such a server? Packages which would be responsible for drawing in the required user services.) If you are actually talking about setting up s6-svscan etc., I think that a) your software and solutions resource consumption is negligible on modern hardware, b) I would consider user services to be a more desktop centric system anyway. B is entirely legit if you make it clear that's what users get. Just to make sure users don't run xeyes when logging in remotely. lmao The format doesn't matter if you control the readers. s6-envdir reads envdirs, envfile reads key=value shell-like files. Choose whatever format works best for you; if you need the variables to be read from a shell as well, the envfile format will work best. It's a question of convenience and preference, really. This is why I am asking all the (more experienced) people on this list. So that I make the best and most informed decision. Since the only purpose is to synchronize interactive shells like bash/zsh/..., this is probably the deciding point: if you need the variables to be read from a shell as well, the envfile format will work best. That means WAYLAND_DISPLAY, by design, is only be accessible to processes that descend from Hyprland. Why do you need to subvert it so unrelated processes can access it? Apologies, I did not explain that well. It basically goes hand in hand with what I have written here: One might now argue that some processes need e.g. a running wayland compositor, but this is the exact case "socket activation" solves. Let's take for example the "foot" terminal emulator(https://codeberg.org/dnkl/foot), which can be run as a server to accept "foot
Re: s6/s6-rc policy for Gentoo
Wouldn't anything this does be solved by just dropping privileges of the corresponding daemons in their startup scripts? No, because the point is to allow users to have their own services, and you definitely don't want them to have access to the root supervision tree. So you basically have to have a separate subtree for each user (a privilege-dropped s6-svscan), and there are a few more policy questions to answer, in particular how to make sure the users cannot flood the root logs by misconfiguring their own logging system. It's doable, but not quite obvious, and it's also not quite obvious how to set up the system so that you don't spawn a supervision tree for inactive users or users who don't use the feature. So there's a little more work involved. This seems like a worse and less flexible version of B to me, I guess the only reason it is even considered is because the seat daemon does all the tracking work for you. Option B does all this does and more if I understand you correctly, thus I think B is straight up the better way. It really depends on your objective. B makes a lot of sense if you want to treat remote logins the same way as seated logins, but there is also an argument to have remote logins be as simple as possible while not minding deploying the red carpet and a whole lot of extra services for seated logins, where the overhead of setting everything up will be negligible compared to the desktop stuff anyway. Does anyone see any other problem arising from B? B is entirely legit if you make it clear that's what users get. Just to make sure users don't run xeyes when logging in remotely. And you probably want an extra supervision tree just for seated stuff anyway, see below. A) The format, do you suggest a FILENAME=content which seems easier to handle with execline and other software's(e.g. dbus) ability to write specific info to an fd which can be redirected to a file? Or do you think a file containing KEY=value, probably playing more nicely with bash and other interactive shells? The format doesn't matter if you control the readers. s6-envdir reads envdirs, envfile reads key=value shell-like files. Choose whatever format works best for you; if you need the variables to be read from a shell as well, the envfile format will work best. It's a question of convenience and preference, really. B) I think I need to make an example to explain this issue properly: I use Hyprland(https://hyprland.org/), which I start from an agetty instance. Hyprland, as any other wayland compositor/DE, sets env's. Most importantly WAYLAND_DISPLAY. It does not write those to a file. Thus I would require the user to add a script launch command to Hyprland's config which launches a script exporting the required(or all?) env's to a dir. This is unacceptable. That means WAYLAND_DISPLAY, by design, is only be accessible to processes that descend from Hyprland. Why do you need to subvert it so unrelated processes can access it? When Hyprland isn't running, there shouldn't be any living processes relying on WAYLAND_DISPLAY. That suggests that you want a separate supervision tree, launched under Hyprland, to host processes that only make sense for a seated login - just like the C case above. I don't think that any hack to get the value of WAYLAND_DISPLAY and store it for access by unrelated processes makes sense. Supervision trees are cool, but they shouldn't be used to bypass normal process hierarchies. Write down exactly what your services' lifetime should be and design accordingly. Thank you for the info, I have the greatest respect for you writing only UNIX compatible software(if that's how to correctly describe it?). I am looking forward to your alternative to PAM. Don't hold your breath - this is a longterm plan, and a considerable amount of work. -- Laurent
Re: s6/s6-rc policy for Gentoo: The logging directory
Concerning the system tree loggers, my first idea is to set an environment variable somewhere in the scripts s6-linux-init provides. Is this even possible? What would be the best place to do this? Any environment variable you want to make available for a whole supervision tree should be added via a "-e var=value" option to your s6-linux-init-maker invocation. For user supervision trees, I suppose you're not using s6-l-i-m, so the best place would be to put the variables in an envdir and use "-E $envdir" (and possibly "-e $var" if you need to substitute $USER or something) in your s6-usertree-maker invocation. If you're not using these tools, the best way is to do the same thing they do: put the variables in an envdir somewhere, and source the envdir both before running s6-svscan and before running your s6-rc-init and s6-rc script. -- Laurent
Re: s6/s6-rc policy for Gentoo
Thanks for your input! As Mobin said, Turnstile from Chimera Linux answers this problem, and also manages the XDG_RUNTIME_DIR folder. Since it actually has hooks to coordinate with the supervisor (unlike elogind, where the systemd-specific code for that in logind is just stubbed out), it makes XDG_RUNTIME_DIR safe to use. All that's needed is a s6-rc-aware backend. I'd write one, but haven't yet because I already have user services set up using Laurent's approach A (i.e. a user service tree that's always up regardless of login) and the fact that s6-rc uses a compiled database introduces some questions existing backends have no answer for (Should the the database be compiled upon login? Should the backend come with a wrapper around s6-rc-compile aware of turnstile's settings? etc.). I am looking at Turnstile, it indeed appears to be the right tool for the job, until Bercot develops an alternative to PAM. Since it actually has hooks to coordinate with the supervisor (unlike elogind, where the systemd-specific code for that in logind is just stubbed out), it makes XDG_RUNTIME_DIR safe to use. I am planning to manage XDG_RUNTIME_DIR with s6-rc, since I am planning to have it hold the livedir. Even though Turnstile is looking like a safe option here, I want to delegate as few critical operation as possible to external tools, so I can easily replace e.g. Turnstile with a future, improved solution. I am not yet sure whether this is the best approach, but up until now it does seem like that. Any critique is welcome! All that's needed is a s6-rc-aware backend. I'd write one, but haven't yet because I already have user services set up using Laurent's approach A (i.e. a user service tree that's always up regardless of login) Regarding A), see my answer here: https://skarnet.org/lists/supervision/3116.html. Additionally, I'd like to mention that A) is the most efficient and simple solution on a single user system, but by no means an elegant one. Also it will will fail on a multi-user system, especially considering resource consumption. I will soon test Turnstile and write a backend. If it works well, it will be in the repo and I am looking forward to improvements to it! and the fact that s6-rc uses a compiled database introduces some questions existing backends have no answer for (Should the the database be compiled upon login? Should the backend come with a wrapper around s6-rc-compile aware of turnstile's settings? etc.). I do not think that the backend should be involved in any compilation of the db. I see two ways the db/source dir changes: A) The user adds a custom service / adds any service to autostart In this case it is also up to the user (with an automation script turning it into one command) to compile and update the s6-rc-db. B) The package manager installs software that includes a script. In that case it is up to the package manager to invoke the script compile and update the s6-rc-db so the user can just start it using the usual commands. A possible alternative would be a system service monitoring all source dirs and recompiling on change. This would exchange user control as well as resource usage for ease of use, which I generally do not like. The approach I use on my machine is prepending the runscripts with `s6-envdir ../../../env` (assuming there's an env folder besides s6-rc's live dir), and touching/writing files there. I don't find this fundamentally inelegant; it follows the general "the filesystem is the database" principle, and avoids introducing an IPC endpoint in the supervisor. I can't argue with your claim about elegance, I would consider it elegant. See https://skarnet.org/lists/supervision/3116.html for the issues I see with this. Read http://jdebp.uk/Softwares/nosh/avoid-dbus-bus-activation.html if you're writing services for D-Bus stuff (like elogind/bluetoothd). (Yes, s6-rc isn't well suited for dynamic events yet, so the second approach of replacing the activation program is ugly, but plenty of bug reports in the Artix Linux forum are related to this — I don't know why they haven't disabled it yet). Thanks for the heads up, will definitely read! To be honest, I did not know dbus even had such capabilities and never even considered using dbus for such a thing. I rather consider dbus a necessary evil for desktop systems. As long as s6-rc does not have dynamic events I will simply not try to hack them in. Gentoo users will probably be fine with that, since most of them are probably using Open-RC which is way farther away from such functionality than s6-rc is. Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo
Hey, thank you for your detailed answer! A. a permanent supervision tree, belonging to a normal user, that runs services as the user, independent from whether the user is logged in. Wouldn't anything this does be solved by just dropping privileges of the corresponding daemons in their startup scripts? That would mean that it is just a needless complication. Anyway, this is the workaround I am using on my machine right now xD. B. A supervision tree that starts with the first login and ends with the last logout. This appears to be what you're working on. Yes. C. A supervision tree that is tied to a graphical session on one seat. That would exclude remote logins via ssh. This seems to be what the Freedesktop people have in mind when they talk about XDG specifications. This seems like a worse and less flexible version of B to me, I guess the only reason it is even considered is because the seat daemon does all the tracking work for you. Option B does all this does and more if I understand you correctly, thus I think B is straight up the better way. One might now argue that some processes need e.g. a running wayland compositor, but this is the exact case "socket activation" solves. Let's take for example the "foot" terminal emulator(https://codeberg.org/dnkl/foot), which can be run as a server to accept "footclient" terminal emulator instances, saving memory and startup time. The server can only be startet once a wayland compositor is up and running. Using "socket activation"(fd-holding) it can be configured to only be started once the first instance of "footclient" is invoked, which can only happen once the compositor is up thus solving this issue completely. This should be applicable to most if not all software with this limitation. Does anyone see any other problem arising from B? You're not the only one working on s6-rc user services for Gentoo: see https://skarnet.org/lists/supervision/3074.html :) You should definitely try and coordinate with Alexis! And also with other people who hang on the #s6 channel on oftc.net and may have more ideas to share. Thanks for the intel! Generally speaking, when I have a set of environment variables that need to be shared between unrelated sets of processes, I put them in an envdir, and source the envdir whenever the variables are needed. One way or the other, the only reliable data sharing tool you have across process trees is the filesystem. I thought about this, too. And I see two issues to solve: A) The format, do you suggest a FILENAME=content which seems easier to handle with execline and other software's(e.g. dbus) ability to write specific info to an fd which can be redirected to a file? Or do you think a file containing KEY=value, probably playing more nicely with bash and other interactive shells? B) I think I need to make an example to explain this issue properly: I use Hyprland(https://hyprland.org/), which I start from an agetty instance. Hyprland, as any other wayland compositor/DE, sets env's. Most importantly WAYLAND_DISPLAY. It does not write those to a file. Thus I would require the user to add a script launch command to Hyprland's config which launches a script exporting the required(or all?) env's to a dir. This is unacceptable. Plan b) Poll the user env and extract on change and write it to the env dir, but how to extract the env? Polling is bad. Plan c) use a notification by a seat manager(e.g. seatd) to run a script that extracts the env and writes it to the env dir, again, how to extract the env? This is also bad, since this will most likely end up being seatd specific, or at least bound to a set of supported seat managers. Does anybody have a better idea? I'm not going to write such a program in the s6 suite, because all the stuff around PAM and utmp is 1. very Linux-specific and 2. extremely brittle and badly/underspecified. At some point, however, I intend to take a good look at PAM and brainstorm about a replacement, because the current situation is just holding with massive amounts of duct tape, good will and headaches, and this makes me fearful for the future. Thank you for the info, I have the greatest respect for you writing only UNIX compatible software(if that's how to correctly describe it?). I am looking forward to your alternative to PAM. In any case, be wary of the trap of using XDG_RUNTIME_DIR to host your user supervision tree. It *looks* like the ideal place to do so, but in case of a desktop session, it's deleted too early and you don't have time to properly terminate your services. Other people who have experience with running user services on a desktop will talk about this better than me. I will open a separate thread on the XDG Base Directory Specification, since I consider this an important point. Generally I'd like to use XDG_RUNTIME_DIR but have it managed by the the s6-rc system service providing the user service tree. Thus it should be
Re: s6/s6-rc policy for Gentoo
I think "turnstile" is a suitable option for this purpose. It's designed in three parts: a PAM module for detecting logins, a Daemon and some service supervisor loader scripts (backends). Currently it does support Dinit and Runit as backends but there should not be any problem around writing a backend for s6-rc. See https://github.com/chimera-linux/turnstile for project itself and more info. Thank you for your suggestion, this looks very promising. I will read into pam and write a local ebuild to install and test turnstile. This ebuild shall then be part of the overlay. Anyhow, it seems this is the best solution until Bercot comes up with an alternative to PAM and utmp. Paul OpenPGP_0x71C7C85A2EA30F62.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: s6/s6-rc policy for Gentoo
1) A service monitoring logged in users, starting the user supervision tree on the first login of a user and stopping it once the user logs out from the last shell/display manager Ah, user services. They're a complicated matter, and their exact definition varies depending on the distro. They're very much tied to distro policies, which is why I haven't written support for them in s6, apart from s6-usertree-maker that may or may not be useful to you. When you say "user services", it generally means one of these things: A. a permanent supervision tree, belonging to a normal user, that runs services as the user, independent from whether the user is logged in. B. A supervision tree that starts with the first login and ends with the last logout. This appears to be what you're working on. C. A supervision tree that is tied to a graphical session on one seat. That would exclude remote logins via ssh. This seems to be what the Freedesktop people have in mind when they talk about XDG specifications. You're not the only one working on s6-rc user services for Gentoo: see https://skarnet.org/lists/supervision/3074.html :) You should definitely try and coordinate with Alexis! And also with other people who hang on the #s6 channel on oftc.net and may have more ideas to share. 2) An elegant way of synchronizing environment variables between the users supervision tree and its services and the users login shell/compositor/... Generally speaking, when I have a set of environment variables that need to be shared between unrelated sets of processes, I put them in an envdir, and source the envdir whenever the variables are needed. One way or the other, the only reliable data sharing tool you have across process trees is the filesystem. Regarding 1) the best idea I currently is to have a daemon monitoring /var/run/utmp, starting an sub-process/s6-rc service for each user appearing there and stopping this sub-process/s6-rc service once the last login instance of the user vanished from that file. Since I have very little programming experience, I wanted to as you, Bercot, whether you consider this a good idea and if you do, whether this would be worth a s6 program. Can this be achieved in a better way? Since you're going with option B, indeed you'll need something to detect logins, but relying on utmp is a risky business, and you don't want to interface with PAM yourself. Having a third-party program dedicated to that is probably the right approach; Mobin mentioned turnstile, this looks like a promising option. I'm not going to write such a program in the s6 suite, because all the stuff around PAM and utmp is 1. very Linux-specific and 2. extremely brittle and badly/underspecified. At some point, however, I intend to take a good look at PAM and brainstorm about a replacement, because the current situation is just holding with massive amounts of duct tape, good will and headaches, and this makes me fearful for the future. In any case, be wary of the trap of using XDG_RUNTIME_DIR to host your user supervision tree. It *looks* like the ideal place to do so, but in case of a desktop session, it's deleted too early and you don't have time to properly terminate your services. Other people who have experience with running user services on a desktop will talk about this better than me. -- Laurent
Re: s6/s6-rc policy for Gentoo
On ۱۴۰۳/۴/۱۵ ۱۷:۳۹, Paul Sopka wrote: Hey everybody I am currently working on implementing boot scripts, system services, user services and general policy for Gentoo with s6/s6-rc. I will soon (once I consider it acceptable) publish a github repo of my current state, so others can criticize, improve and suggest components. The plans is to, after some fleshing out, open another repo containing an overlay with a profile and some packages, so it can be easily installed for testing purposes. In the best case this shall once be merged into official Gentoo. Hi! That's really nice and I'm really excited about that repo :) Currently I see two major things I still need to solve: 1) A service monitoring logged in users, starting the user supervision tree on the first login of a user and stopping it once the user logs out from the last shell/display manager I think "turnstile" is a suitable option for this purpose. It's designed in three parts: a PAM module for detecting logins, a Daemon and some service supervisor loader scripts (backends). Currently it does support Dinit and Runit as backends but there should not be any problem around writing a backend for s6-rc. See https://github.com/chimera-linux/turnstile for project itself and more info. Best Regards