3.1.2.1 Critique of the System V init System
3.1.2.1.1 SysV Benefits
3.1.2.1.1.1 Simplicity
Creating service files is easy with SystemV init since they are simply shell scripts. To enable/disable a
service in a particular runlevel, you only need to create/remove a symbolic link in a particular directory or
set of directories.
3.1.2.1.1.2 Guaranteed Ordering of Services
This is achieved by init running the scripts pointed to by the symbolic links in sequence. The relative order
in which init invokes these scripts is determined by a numeric element in the name: lower numbered
services run before higher numbered services.
3.1.2.1.2 SysV Limitations
3.1.2.1.2.1 Non-Optimal Performance
The traditional sequential boot system was appropriate for the time it was invented, but by modern
standards it is "slow" in the sense that it makes no use of parallelism.
It was designed to be simple and efficient for Administrators to manage. However, this model does not
make full use of modern system resources, particularly once it is recognised that multiple services can
often be run simultaneously.
A common "hack" used by Administrators is to circumvent the serialisation by running their service in the
background, such that some degree of parallelism is possible. The fact that this hack is required and is
common on such systems demonstrates clearly the flaw in that system.
3.1.2.1.2.2 Server-Centric
In the days of colossal Unix systems with hundreds of concurrent users, where reboots were rare, the
traditional SysV approach was perfect. If hardware needed replacing, a system shutdown was scheduled,
the shutdown performed, the new hardware was installed and the system was brought back on-line.
However, the world has now moved on. From an Ubuntu perspective, a significant proportion of users run
the desktop edition on portable devices where they may reboot multiple times a day.
3.1.2.1.2.3 Assumes Static Hardware at all Times
Modern Linux systems can deal with new hardware devices being added and removed dynamically
("hot-plug"). The traditional SysV init system itself is incapable of handling such a dynamically changing
system.
3.1.2.1.2.4 Every Service Does Heavy Lifting
Most service files are fairly formulaic. For example, they might:
• perform initial checks, such as:
• ensuring no other instance of a daemon is running.
• checking the existence of a directory or file.
• removing old cache files.
• ensure dependent daemons are running.
• spawn the main service.
Document generated from reStructuredText plaintext markup source on 2013-10-16 at 14:05:26 from Bazaar
branch branch. See Upstart Documenters and Upstart Cookbook. (revision $Revision-Id$).