On Fri, 10 Apr 2015 18:41:45 -0700
Aristomenis Pikeas <pikeas_at_gmail.com> wrote:
[snip]
> For a bit of context, my goal is the simplest init system that could
> possibly work, to be run inside of a docker container.
<warning>Everything I say here is sort of academic. Also, a
lot of the things I say about daemontools are probably true of
s6 too.</warning>
Hi Aristomenis,
I always thought the simplest possible init system is Rich Felker's
init; the one whose listing is at the bottom of this blog entry:
http://ewontfix.com/14/
Theoretically, Rich Felker's init is all you need in order to init,
pushing things like process management to be run by /etc/rc or whatever
you want to call that shellscript. I was able to init with Rich Felker's
script going to OpenRC for process management (such as it is in
OpenRC), but there were problems with reboots requiring journal
restores, and other problems.
It's surprising I didn't attempt to use Rich Felker's init to run
daemontools or daemontools-encore, with /etc/rc doing things like
starting udev (or vdev or whatever) and devfs and network
initialization, and finally running daemontools (via svscanboot) to
manage processes such as virtual terminals and daemons. As far as
sending all log messages to stdout, I don't know if daemontools can do
that, but I know daemontools can send all log messages to the same
file, assuming the daemontools log run scripts are configured to do
that.
> I need to
> start services and gracefully handle SIGTERM/SIGKILL, with everything
> logged to standard out. That's about it. But this is proving to be
> difficult with s6.
Daemontools correctly handles SIGTERM/SIGKILL, if by "correctly" you
mean restarting it. With daemontools (and I believe s6 too), the way to
stop a daemon is with the svc -d command.
> I've been chipping away at things, but it's slow
> going between understanding all of the tricky bash-isms and learning
> about all of the relevant s6 components.
I'm under the impression that s6 offers use of the execline language as
a way to avoid bash-isms. I found execline's documentation insufficient
for me to learn it, but my impression is its purpose is to provide you
with a language that's less tricky and more determinant and more
versatile than bash.
> If any of the four of you, or anyone else on this list, could provide
> some guidance, I'd greatly appreciate it. I'm convinced that s6 is a
> better solution than runit, but at this point I may switch back, as
> things mostly Just Work.
I think s6 has a documentation problem. I compiled it, but was never
able to get it to run, mostly because I was unable to find, in the
docs, what to do after I got it compiled. And there were way too few
examples of execline code, and I couldn't figure out the language logic
from the descriptive diagrams.
As far as s6 vs runit, my impression is that s6, runit, nosh and perp
are all daemontools-influenced inits that, relative to the entire
constellation of inits out there, are all excellent and very similar to
each other. Runit happens to be the one I was able to actually get
running, but if I were as systems-programming smart as the average
person on this list, I'm sure I could have gotten all four running. And
once again, all of them have documentation problems. Once runit, s6,
perp and nosh have documentation useful for the average person, the
world will be a wonderful place.
By the way, if you're looking for a simple init, consider Epoch:
http://universe2.us/epoch.html . In my opinion it's the best documented
of all init systems, and in my opinion it's the quickest and easiest to
get running on any old random Linux machine (can't run on BSD, but
neither can docker). Unfortunately, it's not daemontools derived and
therefore doesn't manage processes in the foreground with all the
advantages foreground management confers. And it spawns processes
consecutively, by number, rather than concurrently, so you might not
want to use it to init something with fifty daemons. But it's still
pretty good, and it's a good learning tool, IMHO.
SteveT
Steve Litt
Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28
Received on Sat Apr 11 2015 - 15:36:49 UTC