Suckless Init: was anopa: init system/service manager built around s6

From: Steve Litt <>
Date: Wed, 22 Apr 2015 08:51:57 -0400

On Sat, 11 Apr 2015 18:50:12 +0200
Laurent Bercot <> wrote:

> On 11/04/2015 17:36, Steve Litt wrote:
> > 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:
> >
> >
> >
> > Theoretically, Rich Felker's init is all you need in order to init,
> Actually, this is one of the few times Rich is wrong. :)
> He says "start the real init script and then just reap zombies", but
> that's not enough. PID 1 should start another program *and supervise
> it* (or reboot when that other program dies).

Thanks Laurent!

In my search for ever simpler inits (not that I'll necessarily use
them), I've come across Suckless Init:

I've attached the .c and the .def.h programs: It's MIT license so this
is legal.

Anyway, looking at the C program, it looks to me like this init runs
its child once instead of supervising it, just like Rich Felker's init.
And wrapping the spawn of the rc file would do no good --- just prevent
the code from reaching the part that listens for signals. Nor would
putting the whole thing in a loop help: If the rc program (presumably
PID 2) went down, it wouldn't respawn until some descendent sent a
signal, which isn't guaranteed.

Do I have that right?

The reason I'm interested in Suckless Init is it's 89 lines of
semi-understandable C, and it handles poweroff and reboot in very
understandable ways.

The following doesn't fix the flaw you point out, namely, that if PID 2
goes down you have a brick you need to unplug, but I think it would
reduce the likelihood...

The rc file could do nothing but exec a master daemontools,
daemontools-encore, or s6-svscan, which itself could manage a few
different instances of daemontools, daemontools-encore, or s6-svscan,
each with its own version of the /service directory. So everything
except PID 2 would be managed. Perhaps one of the grandchild services
could be something that looks to make sure PID2 is still running, and
if not, sends a signal to PID1 to do a special, diagnostic type of
shutdown (I'd need to use a fourth signal/shellscript pair in
config.def.h). Or maybe I could put code in the sinit.c listen loop
that every time it got a signal it checked for its direct child, and
executed shutdown if that child didn't exist.

The preceding are incomplete kludges, but they might be for a good
cause: An 89 line independent init plus a separate process manager is so
understandable as to form a proof of concept for somebody learning
about init.



Steve Litt
April 2015 featured book: Twenty Eight Tales of Troubleshooting

Received on Wed Apr 22 2015 - 12:51:57 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC