> Date: Fri, 5 Aug 2016 13:34:31 +0200 > From: Hadrien LACOUR <hadrien.lac...@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
