Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to SafariWhen comparing SysVinit vs runit, the Slant community recommends runit for most people. In the question“What are the best Linux init systems?” runit is ranked 2nd while SysVinit is ranked 5th. The most important reason people chose runit is:
After the system's one time tasks (stage 1) are done, the system services are started up in parallel. The operating system's process scheduler takes care of having the services available as soon as possible.
Specs
Question Ranking
Pros
Pro Simple to understand
Pro Very stable
Since sysvinit does only one thing (initialize the system) and one thing only, it's very stable and it's impossible for it to fail for any problems unrelated to booting the system.
Pro Better boot time and overall performance
It boots up really fast if you use it on a desktop system.
Pro No feature creep
It is an init system nothing more.
Pro Easy temporary disabling of init scripts
Just rename the script to disable in /etc/init.d, i.e. /etc/init.d/whatever to whatever.disabled to disable the script and rename it back to whatever to enable it again.
Pro Does not stop booting if something fails
It just works, misconfiguration of a third party service wont break booting.
Pro Configuration based in text files, nothing hidden in the system as it can be done with binary configuration files
Pro Fast, parallel startup
After the system's one time tasks (stage 1) are done, the system services are started up in parallel. The operating system's process scheduler takes care of having the services available as soon as possible.
Pro Small and Unix-like
One of the runit project's principles is to keep the code size small. As of version 1.0.0 of runit, the runit.c source contains 330 lines of code; the runsvdir.c source is 274 lines of code, the runsv.c source 509. This minimizes the possibility of bugs introduced by programmer's fault, and makes it more easy for security related people to proofread the source code.
The runit core programs have a very small memory footprint and do not allocate memory dynamically.
Pro Easy to use
Simple scripts linked to the proper directory is all that's needed to bring a service up at boot, and everything is up and running quickly.
Pro Init purity - does what an init system must do and nothing more
UNIX philosophy, easy to add new services, easy to manipulate, really fast.
Pro Supported by several Linux plumbers
Myself included. Development is no longer stalled.
Pro Runs on every POSIX system
Pro Fast and easy to use
Pro Faster boot time than with systemd
Faster on older systems, especially those running on HDDs.
Cons
Con Duplicated implementation for every service
Every init script needs to reinvent the wheel for every script: argument processing, start/stop/restart/reload/status/whatever processing, finding/clearing/creating PID files, sourcing defaults, building and setting configuration options, so on and so forth.
Con Can lead to slow boot
Since init starts tasks serially, it has to wait for a certain task to finish in order to start the next one. But when startup processes end up I/O blocked, this leads to considerable delays during boot.
Con Launches a bunch of processes to launch a process
Every init script spawns at least sh/dash/bash, and probably also additional processes such as cat, echo, start-stop-daemon, etc, just to start a single daemon that may not even be needed at the time of boot. This massive overhead results in poor performance, and is a killer for embedded systems.
Con Awkward runtime dependency handling
Comes with a directory tree of symlinks to handle the runtime dependencies with links like S01whatever and K11whatever to start/stop services in a specific runlevel. Writing init scripts that conform to the LSBInit standard of LSB, which does allow to define the dependencies in the script header, doesn't always get you covered.
Con Fragile
Scripts can be broken easily, specially if your machine state changes constantly (like almost all modern computers).
Con Follows UNIX philosophy
Yes. This is a CON. Unix Philosophy was a set of guidelines that pretty much made sense in 60 and 70's machines. Trying to follow that instead of the material reality of computing makes software crippled, barely usable and prone to hit dead ends.
Con Initscripts is not portable
It is virtually impossible to write portable sysvinit-scripts.
Con Hard to write sysv-initscripts
As one needs programming skills (opposed to a declarative style).
Con Not GPL
Con Slow
Con Development stalled
Last patch was back in 2014.
