> Date: Fri, 5 Aug 2016 13:34:31 +0200
> From: Hadrien LACOUR <hadrien.lacour_AT_openmailbox.org>
>
> On Fri, Aug 05, 2016 at 08:26:42AM -0300, Marc Collin wrote:
> > I got introduced to s6-rc [0] lately.
> > Do you guys have any experience with it?
> >
> > [0] http://skarnet.org/software/s6-rc/
> >
>
> When I compared daemontools, runit and this one, I thought it was the best.
> Nice comparison: http://skarnet.org/software/s6-rc/why.html
besides hating things, I'd share my findings/arguments.
During my experience, I learned to dislike init system with static
configuration. sinit (and probably a few others) at least allow you to
do things the way that the environment requires, based on conditions
that may not be supported in your init system, opposed to what is
commonly agreed as the best approach on a desktop.
Service dependency is not the job of the init system, each service
should be able to determine for itself if it lacks dependencies.
You should not copy this information to the init system, as it will not
be able to deal with all corner cases for your service anyway.
Importing service dependencies does:
* not speed up booting, since you just have to start things in the right order.
systemd does not boot (fast) based on dependencies, but on service
start order declarations (relative to other services)
* hide problems where your service does not properly deal with a failing
service.
Service dependency definitions also suffer from incomplete views on the
system. It can only work if its perfectly defined, which unevitably does
not work when a GUI programmer creates a nice program. He cannot import
it into such (dependency based) init system. I've met those guys, it
just doesn't work, without disliking such people!
Service monitoring on the other hand is, IMO, always required.
In normal operation, you simply don't want to manually restart a service
when the service failed for some reason. Just launch the process again!
Based on these findings, I wrote rund [0], inspired by sinit.
It addresses my concerns, and performs better than systemd for booting,
footprint, RAM usage, monitoring, modification by regular programmers,
and operator intervention.
In fact, doing better than systemd wasn't that difficult for most
criteria. The reason it can boot just a little faster is purely
bloat-related. systemd takes at least 10MB, and needs to read enormous
archives of service definitions.
rund definitely handles watchdogs better, something I needed for
embedded systems. I believe pid 1 should deal with hardware watchdogs,
but that's another discussion.
Compared to sysvinit (with inittab alone, without the /etc/init.d/
runlevels) or busybox init, rund is easier to tune to your system,
without loosing the service monitoring.
Most sysvinit systems drop service monitoring for flexible, static
configuration! That's the void that systemd has filled.
The API (commandline from the rund client) is quite complete, I'm not
sure that the interface between client and pid1 is stable yet.
I might shift logic from daemon to client, when I get to it.
I have not yet an enormous set of scripts to start services, because,
similar to sinit, the power is that you can choose how to organize
things.
[0]
https://github.com/kurt-vd/rund
Kind regards,
Kurt
Received on Sun Aug 07 2016 - 21:12:04 CEST