The shortcomings of SysV Init and upstart
The first problem with SysV is that of its rather lengthy boot-up times. When you boot up a SysV machine, all of its services have to start up in sequential order. That might not be so bad on a normal desktop machine, but it can be a bit problematic on a server that needs to run lots of services. In that case, each service would have to wait its turn to start, which could take a while.
The next problem with SysV is its complexity. Instead of simple, easy-to-understand configuration files, SysV does everything with complex Bash shell scripts. The init scripts that control system services all have to be assigned a priority number, so that services will start and stop in the proper order. Take, for example, the init script that starts the Apache web server on a CentOS 5 machine. First, we can see that it's a fairly lengthy script, as shown here:
[student@localhost init.d]$ pwd /etc/init.d [student@localhost init.d]$ ls -l httpd -rwxr-xr-x 1 root root 3523 Sep 16 2014 httpd [student@localhost init.d]$ wc -l httpd 131 httpd [student@localhost init.d]$
You can see from the wc -l output that it consists of 131 lines. As you can see here, 37 of those lines are comments, which still leaves us with 94 lines of actual code:
[student@localhost init.d]$ grep ^# httpd | wc -l 37 [student@localhost init.d]$
Look inside, and you'll see that it's quite complex and convoluted. Here's just the first part of it:
Figure 1.1 – An old-fashioned SysV Init script
Toward the end of the script, you'll see the code that stops, starts, restarts, and reloads the Apache daemon, as shown here:
Figure 1.2 – The start, stop, restart, reload section of an init script
This code, or code similar to this, has to be in every init script so that the human user can control the daemon. To complicate things even more, developers didn't always write this code consistently for different programs. So, for example, a status display for one daemon didn't always look the same as the status display for another daemon.
Then, there's the problem of inconsistent implementation across the different families of Linux distros. With SysV, there were at least three different methods of implementation. Red Hat-type distros used one method, Debian-type distros used another method, and Slackware-type distros use yet another. For example, the Red Hat way of controlling services required using the service and chkconfig commands. When working with Debian-type systems, I always used to have to look up the service management commands, because I could never remember them. With Slackware, you don't have any service management commands. To enable or disable a service on a Slackware machine, you just set or remove the executable permission from the appropriate init script.
Runlevels were also a source of confusion, because each family of distro had its own set of runlevel definitions. For example, here are the definitions for the graphical runlevel:
- The Red Hat family used runlevel 5.
- The Slackware family uses runlevel 4.
- The Debian family used no specific runlevel for either text mode or graphical mode. Instead, you enabled or disabled graphical mode by enabling or disabling the X server daemon.
So, you can see that this was all quite confusing, especially for anyone who worked in a mixed environment. It should be fairly obvious that we needed something that was a bit less confusing.
As if this weren't enough, there was also the issue of performance. SysV worked well in its day, when computing hardware was more primitive. But, on modern hardware with multiple CPUs that each have multiple cores, we need something a bit more robust. Ubuntu's upstart was supposed to fix this, but it didn't quite live up to its promise. Nowadays, Upstart is completely dead, but there are still some diehards who refuse to give up SysV. In the enterprise, systemd is king.