When comparing SysVinit vs Upstart, the Slant community recommends SysVinit for most people. In the question“What are the best Linux init systems?” SysVinit is ranked 5th while Upstart is ranked 6th.
Specs
Ranked in these QuestionsQuestion 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 Event based startup was fantastic.
Since it is event based, it was simple to have interdependent services emit status messages each other. Service start ordering and shutdown was easily managed in one conf file.
The "lazy" start of systemd is BS and is a mess to debug . service unit files have no clue what another service state is. The maintainers add arbitrary timers that add more complexity and more init hangs. The systemd documentation is poor. When a service fails to start (or stop) systemd follows the Microsoft model of not telling the reason why.
Pro Simple .conf file in /etc/init
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 Ubuntu abandoned it
The original developers (Canonical) seem to have abandoned this project. At least they're no longer using it in Ubuntu.
Con It was just sysvinit or systemd in disguise
It really just offered a barely more intuitive way to create init scripts for the actual init system running behind upstart.
