9. Starting Your Software Automatically on Boot

The way Linux starts (and stops) all its subsystems is very simple and modular. Lets you define initialization order, runlevels etc

9.1. From BIOS to Subsystems

Lets review what happens when we boot Linux:

  1. The BIOS or a bootloader (lilo, zlilo, grub, etc) loads Linux Kernel from disk to memory, with some parameters defined in the bootloader configuration. We can see this process watching the dots that appear in the screen. Kernel file stays in the /boot directory, and is accessed only at this moment.

  2. In memory, Kernel code starts to run, detecting a series of vital devices, disk partitions etc.

  3. On of the last things Kernel does is to mount the / (root) filesystem, that obrigatoriamente must contain the /etc, /sbin, /bin and /lib directories.

  4. Immediately behind, calls the program called init (/sbin/init) and passes the control to him.

  5. The init command will read his configuration file (/etc/inittab) which defines the system runlevel, and some Shell scripts to be run.

  6. These scripts will continue the setup of system's minimal infrastructure, mounting other filesystems (according to /etc/fstab), activating swap space (virtual memory), etc.

  7. The last step, and most interesting for you, is the execution of the special script called /etc/rc.d/rc, which initializes the subsystems according to a directory structure under /etc/rc.d. The name rc comes from run commands.

9.2. Runlevels

The runlevels mechanism lets Linux initialize itself in different ways. And also lets us change from one profile (runlevel) to another without rebooting.

The default runlevel is defined in /etc/inittab with a line like this:

Runlevels are numbers from 0 to 6 and each one of them is used following this standard:

You can switch from one runlevel to another using the telinit command. And you can see the current runlevel and the last one with the runlevel command. See bellow how we switched from runlevel 3 to 5.

bash# runlevel
N 3
bash# telinit 5
bash# runlevel
3 5

9.3. The Subsystems

Subsystems examples are a web-server, data base server, OS network layer etc. We'll not consider a user oriented application (like a text editor) as a subsystem.

Linux provides an elegant and modular way to organize the subsystems initialization. An important fact to think is about subsystems interdependencies. For instance, it makes no sense to start a web-server before basic networking subsystem is active.

Subsystems are organized under the /etc/init.d and /etc/rc.d/rcN.d directories:


All installed Subsystems put in this directory a control program, which is a script that follows a simple standard described bellow. This is a simplified listing of this directory:

/etc/rc.d/rcN.d (N is the runlevel indicator)

These directories must contain only special symbolic links to the scripts in /etc/init.d. This is how it looks:

Pay attention that all link names has a prefix starting with letter K (from Kill, to deactivate) or S (from Start, to activate), and a 2 digit number that defines the boot activation priority. In our example we have HTTPd (priority 75) starting after the Network (priority 10) subsystem. And the Firewalling subsystem will be deactivated (K) in this runlevel.

So to make your Software start automatically in the boot process, it must be a subsystem, and we'll see how to do it in the following section.

9.4. Turning Your Software Into a Subsystem

Your Software's files will spread across the filesystems, but you'll want to provide a simple and consistent interface to let the user at least start and stop it. Subsystems architecture promotes this ease-of-use, also providing a way (non obrigatoria) to be automatically started on system initialization. You just have to create your /etc/init.d script following a standard to make it functional.

Example 6. Skeleton of a Subsystem control program in /etc/init.d

# /etc/init.d/mysystem
# Subsystem file for "MySystem" server
# chkconfig: 2345 95 05	(1)
# description: MySystem server daemon
# processname: MySystem
# config: /etc/MySystem/mySystem.conf
# config: /etc/sysconfig/mySystem
# pidfile: /var/run/MySystem.pid

# source function library
. /etc/rc.d/init.d/functions

# pull in sysconfig settings
[ -f /etc/sysconfig/mySystem ] && . /etc/sysconfig/mySystem	(2)

.	(3)

start() {	(4)
	echo -n $"Starting $prog:"
	.	(5)
	[ "$RETVAL" = 0 ] && touch /var/lock/subsys/$prog

stop() {	(6)
	echo -n $"Stopping $prog:"
	.	(7)
	killproc $prog -TERM
	[ "$RETVAL" = 0 ] && rm -f /var/lock/subsys/$prog

reload() {	(8)
	echo -n $"Reloading $prog:"
	killproc $prog -HUP

case "$1" in	(9)
		if [ -f /var/lock/subsys/$prog ] ; then
			# avoid race
			sleep 3
		status $prog
	*)	(10)
		echo $"Usage: $0 {start|stop|restart|reload|condrestart|status}"
exit $RETVAL
Although these are comments, they are used by chkconfig command and must be present. This particular line defines that on runlevels 2,3,4 and 5, this subsystem will be activated with priority 95 (one of the lasts), and deactivated with priority 05 (one of the firsts).
Besides your Software's own configuration, this script can also have a configuration file. The standard place for it is under /etc/sysconfig directory, and in our case we call it mySystem. This code line reads this configuration file.
Your script can have many functions, but it is obrigatorios the implementation of start and stop methods, because they are responsible for (de)activation of your Subsystem on boot. Other methods can be called from the command line, and you can define as much as you want.
After defining the script actions, the command line is analyzed and the requested method (action) is called.
If this script is executed without any parameter, it will return a help message like this:

bash# /etc/init.d/mysystem
Usage: mysystem {start|stop|restart|reload|condrestart|status}
Here you put your Software's specific command.

The mysystem subsystem methods you implemented will be called by users with the service command like this example:

You don't have to worry about managing the symbolic links in /etc/rc.d/rcN.d. The chkconfig command makes it for you, based on the control comments defined in the beginning of your script.

Read the chkconfig manual page to see what more it can do for you.

9.5. Packaging Your Boot Script

When you'll create the RPM, put your Subsystem script in /etc/init.d and do not include any /etc/rc.d/rcN.d link, because it is a user decision to make your subsystem automatic or not. If you include them and the user makes any change, the RPM file inventory will become inconsistent.

The symbolic links must be created and removed dynamically by the post-installation and pre-uninstallation process of your package, using the chkconfig command. This approach guarantees 100% package and filesystem consistency.