On Tue, Sep 8, 2015 at 10:04 PM, Steve Litt <sl...@troubleshooters.com> wrote: > Thanks Colin, > > I used Suckless-Init as PID1 and had Suckless-Init pass the baton to > s6, using LittKit to enable service startup ordering in s6 and > intermixing oneshots and longruns in s6. > > If I want to use s6 as my init, what do I do, just put into my Grub > kernel line init=/usr/bin/s6 or whatever the s6 executable is? > You'd write a stage1 script similar to the one in s6/examples/ROOT/etc/s6-init and write init=/path/to/that/file in your grub line. Basically, that file does all your pre-supervision stuff, then execs into s6-svscan, making your supervision root also your PID1 (sort of a best-of-both-worlds, and part of why s6-svscan is designed to be so bomb-proof). The s6-linux-init-builder project on Laurent's site automates generating that file. > > Is s6-rc something you add to s6, or is it a totally different thing? > Different-ish. You set up all your services (oneshots and longruns), set their dependencies, and then compile a s6-rc dependency db and service directory. After that point, if you want to do dependency-aware service changes, you use s6-rc commands, and if you need to take something down temporarily you use s6-svc or s6-rc depending on if you want to pull down a set of services or not. It's available to play with if you want to try it out (I've been using it since it was first available in mid July, and we've squashed a LOT of bugs). The program for updating a live system without some surgery isn't available yet, which is why it hasn't been officially released, but it totally works. > > Am I understanding you right that s6-rc enables you to order the > startup of managed services, and intermingle those managed services > with one-shots, as necessary? > Yup. A longrun can depend on a oneshot for environmental prep, which can in turn depend on a different longrun having started and signaled the system via the s6-ftrig-* notification framework. > > Also, am I understanding you correctly that, when used as an init, s6 > starts by running a stage 1 script, then execs itself into a > supervision program, and when the user chooses to shut down, runs the > shutdown script? If all of the above is true, it sounds challenging to > run the wait loop, to reap zombies and receive signals, in the same > PID1 that is the service manager. I guess I'll have to read the code. > When triggered, s6-svscan tells all s6-supervise processes to terminate their services and then execs into another script to handle shutdown proper. A reference script for stage 3 is also in the examples directory. All that said, it isn't that bad combining the two into your pid1, you just have to make sure you don't tell it to terminate with s6-svscanctl. Honestly, runit or sysvinit have to handle the same dual juggling of tasks - in runit's case though it only needs to supervise one program (runsvdir) but sysvinit has to supervise everything defined in its inittab so it's a similar level of complexity (more actually, because sysvinit does more than just reap and supervise).
Cheers! -- "If the doors of perception were cleansed every thing would appear to man as it is, infinite. For man has closed himself up, till he sees all things thru' narrow chinks of his cavern." -- William Blake