I have wondered if OpenRC could have scripts that hook into s6 to start services via s6 and run in supervision mode while having OpenRC manage order of process startup and sysvinit handles the remainder of init functionality. In a way you combine sysvinit, OpenRC, and s6 in a harmonious union. It's one way of doing things, but it does give insight into mixing different services to run a system.
-James
________________________________
From: Colin Booth<mailto:cathexis_at_gmail.com>
Sent: 9/8/2015 6:22 PM
To: ale_at_ale.org<mailto:ale_at_ale.org>; supervision_at_list.skarnet.org<mailto:supervision_at_list.skarnet.org>
Subject: Re: [ale] systemd talk from July has slide deck online now
> Hi Jim,
>
> Here are some of the many good inits:
>
> * runit: Serves as both PID1 and typical daemontools-style service
> manager.
>
Runit is a pid1 init, which runs a service manager as a non-pid1
supervision tree root. runit runs a script called `1' to handle all
post-boot initialization oneshots, followed by a script called `2'
which serves to exec into your supervision scanner (runsvdir), and
runs `3' to handle all system teardown.
>
> * s6: Very advanced daemontools-style service manager. Requires some
> other PID1. Sysvinit will fill that bill (without any of the init
> scripts: Just one line in /etc/inittab). Personally, I used
> Suckless-Init to implement PID1, and LittKit to provide
> deterministic startup order of services.
>
s6-svscan is designed to be a stage 2 init and supervision root but
can happily run as a non-init process under another service. Compared
to runit, where pid1 is runit, and it forks out different scripts for
each stage, when run as an init s6 uses a script for stage 1, execs
into s6-svscan for stage 2, and uses a script again for stage 3. I use
s6-svscan as an init at home and as a runsvdir/svscan (daemontools)
non-pid1 supervision scanner at work.
>
> * s6-rc: This is coming out this month: I haven't used it. From what I
> understand, this has raised the bar by combining a top quality PID1
> with the s6 service manager.
>
s6-rc has nothing to do with pid1 init and everything to do with
solving some major problems that supervision suites have. The base s6
service already handles init if you want it to. s6-rc is a system for
handling service ordering dependencies and the ability to call oneshot
scripts from inside of a supervision context. It is true that s6-init
is a lot friendlier when coupled with s6-rc since it allows you to
move most system initialization out of the very delicate stage1
period, but to say it's an init system for s6 does both s6 and itself
a disservice. If anything, s6 is the init and supervisor, s6-rc is the
service manager.
>
> * nosh: Another PID1 plus daemontools-style service manager. Its
> runscripts require a special language, I was unable to compile it
> eight months ago. Judging from the many things I've heard its author
> saying, this should be an excellent init if you can get it running.
>
As far as I know it, nosh started as a new-school init for FreeBSD,
since launchd was never going to happen, and upstart was linux-only.
As it stands, nosh is playing in the same space as upstart, launchd,
and systemd. I haven't used it (I use bsd init + s6 on my one freebsd
system, and straight bsd init on my openbsd router) but I'm sure its
solid.
>
> * Epoch: Trivially easy init system with declarative config file
> instead of init scripts, run scripts, or unit files. If I need to
> alt-init a computer in two hours, I'll be using Epoch.
>
I haven't used it but epoch would make a great init for a supervisor
that wasn't capable of doing that itself. daemontools or
daemontools-encore would do great with epoch sicne 95+% of your
non-boot stuff will be handled by daemontools already. Jonathan, feel
free to correct me if I'm wrong.
>
> * OpenRC: A sort of advanced version of what sysvinit should have been.
> I've used it a couple times. I understand it has the ability to do
> all the same stuff as systemd achieves with its socket-activation. Is
> not capable of automatically rerunning crashed services.
>
OpenRC is a service manager that handles the service half of init
(your rc scripts). It isn't a pid1 but instead hooks into your init,
supervisors, etc to manage service grouping, ordering, and the like.
>
> * RichFelker + LittKit + daemontools-encore: If you want the simplest
> possible init: One that absolutely anybody can understand and
> troubleshoot, this is it. Includes a 16 lines-of-C PID1. You can
> replace RichFelker with Suckless-Init if you want your PID1 to listen
> for SIGCHLD, SIGINT and SIGUSR1 and do the right thing, substitute
> the 83 lines-of-C Suckless Init. You'll need to write your own
> shutdown script, which isn't particularly difficult. If you want to
> know what RichFelker PID1 is, see the bottom of this page:
> http://ewontfix.com/14/
>
Rich Felker's init and suckless init both have one major flaw that
keeps them from being production-ready - they aren't capable of
restarting programs. All other inits on this list are capable of at
least restarting one other program: sysvinit restarts anything in
inittab, s6-svscan restarts anything in its supervise directory, runit
restarts runsvdir. With sinit or Rich Felker init, if your non-pid1
supervision root dies, your system goes vegetable (useless but hasn't
figured it out yet). You can't log in, you can't get it to do
anything, but it won't restart on its own.
>
> * Busybox Init: I know little about it.
>
Afaik, busybox init and suckless init in the same space - a super
trivial init that does nothing but start another program and hang out
reaping children. Hopefully busybox init is capable of restarting
programs so it can keep the supervision tree functional, otherwise it
(like sinit and Rich Felker's toy init) aren't useful in production.
>
> USE CASES:
>
> The main use for OpenRC, IMHO, is when your distro already comes with
> it. Gentoo, Funtoo, Manjaro OpenRC.
>
> Runit and Epoch are high quality, small footprint inits easily
> installed on any Linux not tied down with a bunch of systemd-isms. Both
> are easy to install, easy to configure, both can rerun crashed
> processes (Epoch gives you more choice in the matter). Unless a 1
> second bootup is vital to you, I can't forsee a use case not conducive
> to Runit and Epoch. Servers, desktops, it's all good. Runit also works
> with BSD.
>
Not sure about Epoch, but not wanting to translate all your single
user mode initialization stuff into a non-supported init system is one
use case that I can see. I haven't looked at runit's init stuff in a
while but last I checked it wasn't terribly friendly as a drop-in
replacement to sysvinit.
>
> S6 is a top notch service manager that can be combined with a separate
> PID1 (sysvinit, Suckless-Init, systemd) to init almost any use case.
> Its claim to fame is reliability: You just can't kill it. With the soon
> to come s6-rc, it will be a complete init system of the highest quality.
>
Like I said above, s6 is a great supervisor + init and has been for
ages. From an init perspective s6-rc solves some of the major pain
points that happen when using non-standard inits. In the more general
case s6-rc lets you do proper dependency ordering on supervised
daemons, instead of having them crash until their required services
are up. As Steve said, you can also combine s6 with another init if
you want a really fully featured supervision suite but don't want to
rewrite all the work that your distribution maintainers have done on
post-boot initialization ordering.
>
> (RichFelker|Suckless-Init) + LittKit + any daemontools-style service
> manager is best when your top priority is academic simplicity.
> Conforms to http://ewontfix.com/14/. It can be used to alt-init pretty
> much any Linux OS not glued down with systemd-isms, and it will do a
> good job as such. In reality, these kinds of inits serve more as
> demonstrations: For a production machine you'd probably use runit or
> s6-rc instead.
>
> Busybox Init is used when the priority is tiny and simple.
>
If you're too lazy to write a stage1 execline script for s6, busybox
init + s6 are great. Otherwise, just write 15 lines of execline and
call it done.
Personally, I run about half my systems on their native init (sysvinit
for linux, bsd init for bsd) with most daemons then managed by a
supervisor (runit or s6, mostly depending on the age of the computer,
since I knew about runit before I knew about s6). The other half are
run directly under s6, with the complicated ones (say, my home laptop)
using s6-rc for dependency ordering and others (wireless router) using
s6 straight up since there isn't enough complication there for s6-rc
to help. At some point everything linux will get rebuilt under s6 and
use s6-rc for service management, but that time isn't now.
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
Received on Wed Sep 09 2015 - 03:44:37 UTC