Re: Using runit-init on debian/Jessie in place of sysvinit/systemd

From: Steve Litt <>
Date: Fri, 2 Jan 2015 05:25:48 -0500

On Fri, 2 Jan 2015 01:31:46 +0100
toki clover <> wrote:

> ---------- Forwarded message ----------
> From: toki clover <>
> Date: 2015-01-02 1:30 GMT+01:00
> Subject: Re: Using runit-init on debian/Jessie in place of
> sysvinit/systemd To: Luke Diamand <>
> First, it's a bit crazy to use runit for init+service management
> entirely because:

Doesn't seem a bit crazy to me.

> - It's completely crazy to supervise every service because; first,
> every service
> won't fit in if it's not a daemon;

I'm not sure what the preceding means, but runit is like daemontools,
your run script runs the desired program in the foreground.

If you mean that it's difficult to fit run-once scripts into stage 2,
there are ways to make that possible.

> second supervising every daemon is
> dangerous.


And if there are some daemons you'd rather leave crashed than respawn,
have one stage 2 service that runs all of them, leaves a sentinel file
to prevent it from reruning those daemons, sleeps, and returns 0. So
that service gets rerun every what, minute, hour, whatever (according
to the sleep value), but the sentinal file prevents it from running
those daemons again. Stage 3 deletes the sentinel file.

> - Second, runit (or s6 for that matter) lack any decent service
> dependency, actually both completely ignore the problem (athough s6
> may change this in in a near futur.)

> - Third, do not forget the overhead of supervision (an extra instance
> per daemon.)

How many daemons are you planning on running? Most of the daemons
running on typical desktop distros are edge-case CYA that can be lived
without, and that's probably an improvement.

> Second, stuffing stage 1 `/etc/runit/1' is a bad idea because stage 1
> is very
> sensible... any service that hangs in the foreground will hang booting
> because C-ALT-DEL signal is inactive (see this page for more details

How many scripts/programs/adjustments do you need to make as the
computer boots up? Much of the stuff typical distros run is fluff that
someone with the smarts to replace an init doesn't need.

> So, I would recommend using rc, or even better OpenRC (which is
> available in Debian based OS) to take care of service dependencies
> management and use service supervision for agetty (and sshd and the
> likes if necessary.) (There is a complete solution with runit+OpenRC
> in that thread.)

runit->OpenRC was pretty easy for me to do in the OpenRC edition of
Manjaro. Put:

/usr/bin/openrc sysinit
/usr/bin/openrc boot
/usr/bin/openrc default

in /etc/runit/1

And of course, you need to have runit manage your ttys because OpenRC
can't respawn.

As I remember (I later switched to pure runit and didn't document the
hybrid extensively), you need to jump through some mild hoops if you
want it to shut down elegantly, but it worked just fine without the

> That forums thread has a dangerous implementation with a stuffed
> stage 1 which I split to have only sysinit related services in it and
> then use stage 2
> to fully boot the system and brings it to a desired runlevel. This is
> far more
> safer because a tty will be available to fix anything broken if need
> be.
> Stuffing stage 1 is suicidal...

Two characterizations in the preceding five word sentence, "stuffing"
and "suicidal".

As far as stuffing, you can have more or less calls in /etc/runit/1,
but as long as they're trustworthy, what's the problem? Half of them are
simple shellscripts anyway: You put your daemons in stage 2. Nobody
wants everything plus the kitchen sink in stage 1, but I see nothing
wrong with a short shellscript to bring up udev, a short script with
ip commands to bring up your network, and if necessary a short
shellscript to bring up devfs (and my shellscript for that purpose was
excessively long, but it can be carved to size).

As far as "suicidal", I'd comment that System Rescue CD is standard
suicide prevention. If, while first configuring things, you happened to
get it wrong, you can boot SysRescueCD and undo your last act. Better
yet, in parallel, set up an Epoch init or a sysvinit->OpenRC init so
that if your runit init continually goes south, you can boot the
alt-init and fix the problem.

I wouldn't characterize pure runit as "crazy", I'd characterize it as a
solution that fits many needs and use cases.


Steve Litt *
Troubleshooting Training * Human Performance
Received on Fri Jan 02 2015 - 10:25:48 UTC

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