Subdirectories as service dependencies

[Uros Perisic]

As a daemon supervision suite, I get that this can seems out of scope for
s6 (as opposed to s6-rc), but hear me out.

The log directory is currently treated as a special case, but what if it
didn't need to be? Any subdirectory with an executable run file could be
considered a service dependency. This would allow for dynamic configuration
(expressing dependencies without having to change any files) just by using
symlinks. Further, tightly coupled services would now have self-documenting
structure (e.g. foo, foo/log, foo/server...) Instead of doing what systemd
does and effectively having dashes (-) mean directories

There is a big gap between s6 and s6-rc in terms of the knowledge needed to
use them, and yet I feel this is an often needed feature that shouldn't
pull in everything else s6-rc provides. And it kills a special case, which
is always nice.

Thoughts?

Best,
Uros

Emacs Daemon as Service

[Uros Perisic]

Hi everyone,

I'm kind of stuck here. I'm trying to write an emacs service:
```
#!/usr/bin/execlineb -P
s6-setuidgid uros
emacs --fg-daemon --user uros
```
Though the server starts it cannot connect to the X display. I assume
there's an explicit way to handle this in s6.

Or should I start another supervision tree owned by me? If so how would
s6-rc talk to it? Does it always have to be specified on the command line?

I'm just hunting for best practices here, any help would be appreciated.

Best,
Uros

Re: Question About the Purpose of s6-rc

[Uros Perisic]

Alright, I'm sold. I'm diving into s6. So much control.
Thanks again Colin!

On Fri, Mar 20, 2020 at 2:33 PM Colin Booth  wrote:

> On Fri, Mar 20, 2020 at 01:36:13PM +0800, Uros Perisic wrote:
> > Thanks Colin!
> >
> > That clarifies a lot.
> >
> > The s6-rc -wu  command was a typo, although I had no clue s6-rc has such
> an
> > option as well, so the information is still useful. I meant to say s6-svc
> > -wu . Or am I wrong in assuming that that is the equivalent of
> > runit's sv up ? I went that route because that is the
> recommended
> > way to handle dependencies in runit. I take it s6-svwait is preferred in
> > s6, especially given that there is no polling and hence no cost involved?
>
> The s6-rc command for "bring everything up" is actually `s6-rc -ua
> change'. I don't manually run s6-rc commands that often so I have to
> look up the exact command syntax pretty often.
>
> For light service interdependencies someting like `s6-svok
>  && s6-svwait -U ' is the most
> straightforward way to do it.  You can do `s6-svc -wU '
> instead but that's mixing control and monitoring interfaces so better to
> use s6-svwait which only deals with monitoring. Both s6-svc -wU and
> s6-svwait -U are roughly equivalent to synchronizing with `sv check
> ' but use the native readyness protocol within s6 instead
> of depending on an external check script. Of course, you can use
> s6-notifyoncheck if you need check script functionality, though that too
> wires into the s6 notification protocol.
>
> Do note that waiting on `s6-svc -wu -u' or `sv up' is mostly pointless
> and waiting on `s6-svc -wu' without the -u is entirely pointless except
> in one specific case.  The semantics of up/-wu (vs start/-wU) are such
> that sv/s6-svc will return as soon as the run script itself is launched,
> not when the check has passed. Technically, `sv up' is the same as
> `s6-svc -u', aka purely asynchronous, but in all but the most extreme
> cases -wu should return within a few hundreths of a second since all
> you're waiting on is s6-supervise getting the message and launching
> ./run. The only time that blocking on `s6-svc -wu' makes sense is if you
> have a service that's explicitly down and you want to keep something
> else from starting until you bring the first up. And then, you might as
> well use s6-svwait since it'll be much clearer what you're doing.
>
> Under the hood, s6-svc -w? forks s6-svwait -?, which itself forks
> s6-ftrigrd to monitor the event/ directory. As such, using s6-svc -w?
> without a command is equivalent (though slightly slower) than using
> s6-svwait directly.
>
> --
> Colin Booth
>

Re: Question About the Purpose of s6-rc

[Uros Perisic]

Thanks Colin!

That clarifies a lot.

The s6-rc -wu  command was a typo, although I had no clue s6-rc has such an
option as well, so the information is still useful. I meant to say s6-svc
-wu . Or am I wrong in assuming that that is the equivalent of
runit's sv up ? I went that route because that is the recommended
way to handle dependencies in runit. I take it s6-svwait is preferred in
s6, especially given that there is no polling and hence no cost involved?

All the best,
Uros


On Fri, Mar 20, 2020 at 1:00 PM Colin Booth  wrote:

> On Fri, Mar 20, 2020 at 12:30:15PM +0800, Uros Perisic wrote:
> > If all services are started in parallel, but s6-rc -wu blocks until a
> > service is up, what is the difference between simply putting it in a run
> > script before the exec call, and s6-rc figuring the dependencies out
> ahead
> > of time?
>
> Hi Uros,
>
> For simple setups (a few longruns) where you know the interdependencies
> you are absolutely correct that you could use s6-svwait(1) in run scripts
> to control ordering. The hard part comes in two parts:
> 1. when you don't know the exact dependency set but know that a service
> needs to start after a group of services (lets call it a bundle) are
> started and passing their internal checks.
> 2. if you need to have an initalization script run *after* a supervised
> program is run. For example, the udev coldplug cycle (the thing that
> detects existing hardware) needs a running udev in order to create the
> device nodes and while you could run that as a forked process in the
> udev run script, it really only has to happen once.
>
> It's these two considerations that caused s6-rc to come to being. While
> the first can be handled with a helper function library, the second
> cannot without either dumb tricks (supervised processes that set
> themselves down at termination, or exec into s6-pause, or the like) or a
> system that understands both kinds of services as well as a dependency
> ordering system.
>
> Depending on what you're trying to do, s6-rc may be entirely overkill.
> Like I mentioned at the beginning, if all you're trying to do is start a
> number of services and some of those depend on others before starting
> (for example, a collection of web services and web servers fronting
> them probably want to wait until the services have started before
> bringing up their corresponding web frontend) then blocking in the web
> server run script is totally fine since it's a self-contained service
> pair. For 90+% of the process supervision world this is good enough,
> it's only when you start managing the lifecycle of full systems
> (including containers) or very complex service interdependencies does
> the added complexity of a service manager start to make sense.
>
> Cheers!
>
> P.S. s6-rc -wu blocks until the *last* service in the start set is up.
> If you add some verbosity you'll see multiple services get started, and
> then additional ones being executed as their dependencies become
> available.
>
> (1) or s6-svstat -o ready and an exit on failure, or whatever.
> --
> Colin Booth
>

Question About the Purpose of s6-rc

[Uros Perisic]

Hi all,

I am generally new to daemontools-style init systems (been a runit user for
about 6 months now, looking to try out s6), so I have a few clarifying
questions regarding s6-rc. Forgive me if they stem from my ignorance.

All three bullets here 
essentially boil down to dependency management (with the exception of
one-shot services). But my question is this:

If all services are started in parallel, but s6-rc -wu blocks until a
service is up, what is the difference between simply putting it in a run
script before the exec call, and s6-rc figuring the dependencies out ahead
of time?

Best,
Uros