The way s6 is designed, it doesn't really do "system" services or "user" services, it just does services. I guess this is also why it's a great fit inside containers.
Your services might want to change user (if they're system services), or save data to $HOME (if they're user services). That's purely determined by the service definition itself.
I've been using s6 for user services for over a year now quite happily. I'm using my frontend tool to manage them, and it basically just invokes s6 commands and provides a high-level interface for me to use.
No, that's not about changing users, any init system can do that. It's about having an interface where any unprivileged user can setup services (that could depend on systems services); like cron, basically.
I believe they are talking about a situation where S6 is pid1 / system init, starting "system" services (I know the distinction is not in S6), aka things configured by root. I'd expect DNS, cron, NTP, SSH to be in that list.
Then, also, separately from the pid1 S6, unprivileged users can have their own supervision trees independent of the pid1 instance, but that can depend upon things started by pid1.
Example:
pid1 S6 launches root-configured service, S as part of its supervision tree.
Unprivileged user, U, has a discrete instance of S6, which I'll refer to as pidN S6 with a supervision tree that U controls (e.g. in each user's $HOME). pidN S6 launches a service T which depends on S.
Is there a way for pidN S6 to wait on pid1 S6 to note that S is ready, blocking the launch of T until that notification.
The separate supervision trees part seems trivial based on my understanding of S6.
I also see in the docs that a daemon can signal its own supervising S6 that it is ready, so that S6 can manage the dependencies among multiple services in its supervision tree. The part that seems unclear to me (and the original question-asker) is if there can be cross-supervision-tree dependencies.
The brute-force way to do this would be to have the PID1 S6 launch a pidN S6 process for each user, with the supervision tree defined in that user's $HOME. Then the pid1 S6 can ensure that each pidN instance is dependent upon all PID1 services, so that the user instances only launch after all possible dependencies are initialized. This would still depend on an implicit contract between root and users so that root does in fact launch all upstream dependencies.
Alternatively, I guess you could give fine-grained sudo privileges to each user that gets a pidN S6, so that they can check the status of running daemons under the pid1 S6.
I don't know enough about how s6 work, so I'll probably write stupid things, but how do you start/enable services? By running sh/execline scripts and symlinking them in specific dirs? Well, you need privileges for that, no?
I can "crontab -e" as any user without privilege and edit my own crontab, separate from the root one, that's what I meant.
Your services might want to change user (if they're system services), or save data to $HOME (if they're user services). That's purely determined by the service definition itself.
I've been using s6 for user services for over a year now quite happily. I'm using my frontend tool to manage them, and it basically just invokes s6 commands and provides a high-level interface for me to use.