RE: another distro using runit...

From: James Powell <>
Date: Tue, 21 Oct 2014 02:04:35 +0000

The Runit-for-LFS project actually used a lot of what was done by VoidLinux early on to craft our scriptworks for using Runit as well, before they moved to the segregated bootscripts. We stuck with the monolithic script for Stages 1 and 2.

VoidLinux had systemd at one point but removed it.

The numbers of distributions experimenting with alternatives like OpenRC, Runit, sysv+perp, and even uselessd are all growing but still slowly, but the movement is gaining headway.

I have been experimenting with using cron launched via inittab as a method to bootstrap a Slackware rc.M-like shell script to issue service checks on a regular basis while (re)launching daemons if they are down, and issuing a report log in LFS as well. It's no DJBDTS, Runit, or s6, but it's fun to learn how to use old existing tools in new ways.


> From:
> Date: Mon, 20 Oct 2014 10:52:05 -0700
> Subject: another distro using runit...
> To:
> another distro using runit:
> "runit as native init system and systemd supported optionally."
> Thanks for your hard work!
> I've also made it the default init system for my Airstack base docker
> container...
> I've tried to condense/reduce the runit functionality into simple service
> definition json file:
> Would love to hear any comments you have on the json format.
> Re: runit, a few things I've run into:
> - I haven't found a way to lower the default wait time on init start from
> the current default 1 second. Also not sure if there's a way to lower the
> runsvdir service poll timer below 1 second?
> - With nearly all of my services, I create enable scripts that check for,
> and if necessary set up directories and perhaps even default passwords or
> databases. And I haven't found an elegant way yet to integrate this into
> runit. I think it would be useful to separate out a command for 'enable'
> that would run successfully only once for a service. Or I guess I can
> create some idempotent test that runs before each service run command. But
> that doesn't seem as elegant. Unit already has a concept of a 'check' file
> and a 'finish' file. What do you think about adding support for a 'enable',
> 'start' or 'pre' file that only gets run on service start?
> - John
Received on Tue Oct 21 2014 - 02:04:35 UTC

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