One of the most crucial pieces of any UNIX-like operating system is theinit dæmon process. In Linux, this process is started by the kernel,and it's the first userspace process to spawn and the last one to dieduring shutdown.
During the history of UNIX and Linux, many init systems havegained popularity and then faded away. In this article, I focus on thehistory of the init system as it relates to Linux, and I talk about therole of init in a modern Linux system. I also relate some of the historyof the System V Init (SysV) scheme, which was the de facto standard for manyLinux distributions for a long time. Then I cover a couple moremodern approaches to system initialization, such as Upstart and systemd.Finally, Ipay some attention to how things work in systemd, as this seems to bethe popular choice at the moment for several of the largest distributions.
The Role of InitInit is short for initializer, and it's both a startup manager and asession manager for Linux and other UNIXes. It's a startup manager,because it plays a crucial role in the startup of Linux. It's theprocess that creates or initializes userspace and, ultimately, alluserspace processes. It also may be considered a session manager,because it takes care of many aspects of userspace and its processesonce the system is up and running.
The call to start this process is, in fact, hard-coded in the Linuxkernel. Download the latest kernel sources and look for a functioncalled kernel_init in the file init/main.c. Among the files that theLinux kernel will try to execute is /sbin/init. If Linux cannot findone of these processes, it throws a kernel panic and halts.
The kernel gives the init process an ID of 1 or PID 1. All otheruserspace processes are forked from init, and therefore, PID 1 claimsancestral rights to all other userspace processes. PID 1 alsoautomatically will become the direct parent process of any userspace processthat is orphaned.
A Little Bit of HistoryNow that I have set the stage for the article and given you a very basicunderstanding of what init is and does, I'd like to digress intoa little bit of UNIX history.
There has been a lot of diversity in the initialization schemes forUNIX-like operating systems over time. Two of the most important initschemes that had a historical impact on how different Linux distributionsdo things are the rc scheme used in the 4.4 BSD and the SysV schemeused in SunOS and Solaris.
The 4.4 BSD init system is pretty simple and monolithic. When booting,the kernel runs /sbin/init, which would spawn a shell to run the /etc/rcscript. The /etc/rc script contained commands to check the integrity of harddrives and mount them, start other processes, and start the networkingsubsystem. This scheme was contained completely within a few scripts:namely /etc/rc, /etc/rc.local and /etc/netstart. This scheme also hadno specific shutdown procedure. Init would receive a SIGTERM signal andsend a SIGHUP and/or a SIGTERM to its children, and after all processesexited, it would drop to single-user mode and shut down.
Today, the systems that have inherited the rc initialization scheme areFree-BSD, Net-BSD and the Slackware Linux distribution. These modernsystems have improved quite a bit on the original 4.4 BSD scheme andare much more modular than the original.
Most other Linux distributions have, historically, been adepts of theSysV scheme, which originally was implemented in AT&T UNIX and derivativesystems like Solaris.
System V InitA Linux distribution implementing a SysV scheme can be in one of manydistinct states in which a predetermined number of processes may berunning. These states are called runlevels and to get to a certainrunlevel means that the system is in a certain operational stage.
The meaning for each runlevel may vary based on your distributionof Linux. For example, there are a few distributions (such as Ubuntu) thatuse runlevel 2 to mean multi-user graphical mode with networkingenabled. Others (like Fedora) use runlevel 5 to mean the same thing.
In a SysV Linux machine, the kernel runs /sbin/init as usual,which in turn will load parameters and execute directives definedin /etc/inittab. This file defines the default runlevel for the wholesystem, describes what happens when Ctrl-Alt-Del is pressed, loads keymapfiles, defines which terminals to spawn gettys for, spawns terminal loginprocesses, runs the /etc/init.d/rcS script, and it also influences the orderof execution of other runlevel scripts.
The /etc/init.d/rcS script will put the system in a single-user modein order to finish probing hardware, mount disks, set hostname, set upnetworking and so on. Take a look at /etc/rcS.d/ in a Debian 7 system forall the gory details. Next, /sbin/init will switch itself to the defaultrunlevel to start all the system services. The default runlevel valueis defined in the initdefault line of /etc/inittab.
This actually translates into a call to the /etc/init.d/rc script withthe parameter of 2 for the runlevel value. The rc script will thenexecute all of the K* (for Kill) and S* (for Start) scripts in the/etc/rc2.d/ directory. These are actually links to the real scripts in/etc/init.d/. The names of the links follow the formatS##
A system that uses the SysV scheme usually comes with the service programused to manage the services while the system is running. You can checkon the status of a service, or all services, and start or stop a service,respectively, using the service utility:
$ service
$ service status -all
# service
To manage the assignment of services to a particular runlevel, you canuse a tool called sysv-rc-conf, which manages the setup of all linksin the respective rc directories. You also can switch the runlevel ofthe system at any time when you use the commandtelinit as a privilegeduser. For example, telinit 6 will reboot a SysV system.
The SysV scheme still is in use today in Debian 7 (Wheezy)systems. However, the Debian developers will be changing the init systemin version 8 to systemd. I cover systemd in more detail below, but first,let's look at why we need a new init system.
The Problem with System V InitThe SysV scheme has been great, but it started to show its age aroundthe time when Linux on the desktop gained a little more momentum. When theSysV scheme originally was designed, computers where nothing like theyare today. SysV was not designed to handle certain things well:
USB devices.
External storage volumes.
Bluetooth devices.
The cloud.
The SysV scheme was designed for a world that was static and slow moving.This init scheme originally was responsible only for bringing the systeminto a normal running state after power on or gracefully shuttingdown services prior to shutdown. As a result, the design was strictlysynchronous, blocking future tasks until the current one had completed.
This left the system unable to handle various events that were notrelated to the startup or shutdown of the system. Things that we takefor granted today were really cumbersome to handle elegantly during theheyday of SysV init:
There was no real process supervision—for example, dæmons werenot automatically restarted when they crashed.
There was no real dependency checking. The order of script namingdetermined the order in which they were loaded.
The addition or removal of USB drives and other portable storage/networkdevices while the machine was running was cumbersome and oftentimesrequired a reboot.
There were no facilities to discover and scan for new storage deviceswithout locking the system, especially when a disk might not even power onuntil it was scanned.
There were no facilities to load firmware for a device, which may haveneeded to occur after it was detected but before it was usable.
Inevitably, around the 2005/2006 time frame, severalalternative efforts tried to fix all the issues with the SysVscheme. But the effort that looked most promising during that time wasthe Upstart init project sponsored by Canonical.
123next ›last »
Author Name
Author Description!
Post a Comment