Well generally I hatched the idea in my head when I started looking at how OpenRC can use stacked runlevels and it made me think of the typical stage-2 script which acts as a master controller script to start the supervisor and execute everything in the service directory. Because s6 provides a supervisor and sysvinit provides the executables to bring the system up and/or down, and OpenRC can provide stacked runlevels executing services in parallel, why not use all three in synchronization with each other to perform vital functions betwixt and between the other.
Example:
Typically a service like dbus is started with the stage-2 script executing the /service directory as a whole, but controlling dbus directly requires some abstract commands specific to s6 but nothing else. My idea was why not eliminate the /service directory and have everything ran in parallel via OpenRC, but instead of calling the supervisor to execute everything as just s6, wrap the s6 commands via the start, stop, status, and restart calls in each script. This way OpenRC and s6 utilize equal control over the service, the service runs with supervision, and runs in parallel start up with the necessary state tracker checks of service in the s6 scripts separate from OpenRC.
Basically, s6 gets micromanaged. It sounds complex, but in thinking, it's relatively human in thinking like BSDinit is. You don't technically eliminate stage-2, but create multiple stage-2-like instances unique to each service for tighter control.
Am I making any sense here? Is this workable to some extent? I'm just trying to think outside the box here.
-Jim
________________________________
From: Laurent Bercot<mailto:ska-supervision_at_skarnet.org>
Sent: 9/19/2015 7:52 AM
To: supervision_at_list.skarnet.org<mailto:supervision_at_list.skarnet.org>
Subject: Re: Some suggestions about s6 and s6-rc
On 19/09/2015 14:52, James Powell wrote:
> I don't see it, rc_parallel, as entirely broken, that is if you
> follow proper scripting techniques and create the proper dependency
> prestarts.
Even if you do, it's not guaranteed to work as long as you don't
have a way to notify readiness. In the serial case, OpenRC starts a
subprocess to start a service, and readiness is assumed when the
subprocess exits. That defers readiness test to the subprocess, which
is perfectly reasonable.
With rc_parallel, you just don't wait for the subprocess to exit.
I haven't studied the code in detail, but without any readiness
notification system, there's no way it's going to respect the
dependency graph. It's basically "start everything at the same
time, and yolo". Which defeats the purpose of a dependency-based
service manager.
> I've often wondered if services started via OpenRC could be ran
> wrapped to s6, such as instead of scripting to start the daemon
> normally via direct execution, you start it wrapped via OpenRC by
> executing the s6 run script and stopped by the finish script within
> the OpenRC script acting as a manager layer.
I think that's what the "supervisor=s6" variable does.
See
https://github.com/OpenRC/openrc/blob/master/s6-guide.md
--
Laurent
Received on Sun Sep 20 2015 - 09:19:21 UTC