Startup Using SystemV Init Scripts

The SystemV init scripts and the init program are obsolete and have been replaced by systemd on most modern Linux distributions. This document is maintained for historical purposes only.

The Startup process follows the Boot process. Some people consider Startup as part of the boot process, but it is really not — at least for purists. In a SystemV Linux system, the Boot process ends with loading init. init then initiates the Startup process.

This section covers the Startup process using SystemV which launches the daemons and programs that bring the Linux computer up to a usable state.

Run levels

Run levels define the services to be run by Linux. Each run level provides a different set of services which correspond to various user level capabilities. Some run levels are not used and others provide special functions.

There are seven defined run levels in Linux, run level 0 through run level 6. This goes back to the days of Unix at the old AT&T (before the original breakup) when telephone switches had seven run levels; it was thought that a Unix system should have the same number of run levels. Up to ten run levels are supported by Linux but run levels seven through nine have not been defined by any of the mainstream distributions and are typically not used.

Start Scripts

Each run level uses scripts called start scripts to start and stop services for that run level. These scripts are located in the /etc/init.d directory which is a symbolic link to /etc/rc.d/init.d. Each script should recognize at least three basic parameters, start, stop and restart. They may also recognize other parameters such as condrestart (conditional restart), status, setup and others.

These start scripts are based on the Unix System V start scripts and so may be called System V start scripts.

Each run level has a directory, /etc/rc.d/rcX.d, where X is the number of the run level. Symbolic links in each run level directory link to the scripts in the /etc/rc.d/init.d directory. Each link is named with “K” or “S,” for Kill or Start, and a number which specifies the order in which the scripts are to be run.

For example, a sample listing of the start scripts for run level three looks like that below.

K01dnsmasq -> ../init.d/dnsmasq
K01smartd -> ../init.d/smartd
K01smolt -> ../init.d/smolt
K10psacct -> ../init.d/psacct
K10saslauthd -> ../init.d/saslauthd
K10wine -> ../init.d/wine
K10zvbid -> ../init.d/zvbid
K15httpd -> ../init.d/httpd
K19ntop -> ../init.d/ntop
K20nfs -> ../init.d/nfs
K24irda -> ../init.d/irda
K36mysqld -> ../init.d/mysqld
K50netconsole -> ../init.d/netconsole
K50snmpd -> ../init.d/snmpd
K50snmptrapd -> ../init.d/snmptrapd
K66gpsd -> ../init.d/gpsd
K69rpcsvcgssd -> ../init.d/rpcsvcgssd
K73winbind -> ../init.d/winbind
K73ypbind -> ../init.d/ypbind
K74pcscd -> ../init.d/pcscd
K75netfs -> ../init.d/netfs
K75ntpdate -> ../init.d/ntpdate
K76openvpn -> ../init.d/openvpn
K83bluetooth -> ../init.d/bluetooth
K83nfslock -> ../init.d/nfslock
K83rpcgssd -> ../init.d/rpcgssd
K83rpcidmapd -> ../init.d/rpcidmapd
K84btseed -> ../init.d/btseed
K84bttrack -> ../init.d/bttrack
K84NetworkManager -> ../init.d/NetworkManager
K84wpa_supplicant -> ../init.d/wpa_supplicant
K85racoon -> ../init.d/racoon
K87multipathd -> ../init.d/multipathd
K87restorecond -> ../init.d/restorecond
K87rpcbind -> ../init.d/rpcbind
K89netplugd -> ../init.d/netplugd
K89rdisc -> ../init.d/rdisc
K92ip6tables -> ../init.d/ip6tables
K95firstboot -> ../init.d/firstboot
S01sysstat -> ../init.d/sysstat
S06cpuspeed -> ../init.d/cpuspeed
S08iptables -> ../init.d/iptables
S10network -> ../init.d/network
S11auditd -> ../init.d/auditd
S11portreserve -> ../init.d/portreserve
S12rsyslog -> ../init.d/rsyslog
S13irqbalance -> ../init.d/irqbalance
S15mdmonitor -> ../init.d/mdmonitor
S22messagebus -> ../init.d/messagebus
S24avahi-daemon -> ../init.d/avahi-daemon
S25cups -> ../init.d/cups
S26acpid -> ../init.d/acpid
S26haldaemon -> ../init.d/haldaemon
S26lm_sensors -> ../init.d/lm_sensors
S26udev-post -> ../init.d/udev-post
S30vboxdrv -> ../init.d/vboxdrv
S55sshd -> ../init.d/sshd
S58ntpd -> ../init.d/ntpd
S60apcupsd -> ../init.d/apcupsd
S80sendmail -> ../init.d/sendmail
S85gpm -> ../init.d/gpm
S90crond -> ../init.d/crond
S90xfs -> ../init.d/xfs
S95atd -> ../init.d/atd
S99local -> ../rc.local

Note: The above listing was for one of my early Fedora computers.

When entering a new run level, either at boot time or by using the init or telinit commands to change run levels, the kill scripts are run first and then the start scripts are run for that level. The Kill scripts are run first and then the Start scripts are run. The numbers after the “K” or “S” in the link name help to determine order in which the scripts are run. When two scripts share the same number, the rest of the name is used to determine the sequence which is alphabetic.

The sequence of starting and stopping scripts is very important. For example you want to ensure that the firewall (IPTables) is started before the network, and stopped after the network in order to maintain security.

Run Level Descriptions

Each run level has a specific purpose in Linux. Table 1, below, describes each run level.

Run LevelDescription
0Run level 0 is “shutdown.” This shuts down Linux and powers off the computer.
S or sThis is called single user mode, but the difference between this and run level 1 is that no start scripts are run when entering this level. This is not truly a run level.
1Also known as single user mode but is more accurately referred to as run level 1. This mode is used when the system administrator needs to perform maintenance activities that require no other users be logged in. The scripts in /etc/init.d/rc1.d are run when entering this run level.
2This run level brings Linux to a fully functioning state with the exception that NFS is not active, so NFS file systems will not be mounted.
3Run level 3 tends to be the standard runlevel for text mode operation. It includes NFS functionality.
4Not used.
5Run level 5 is the same as run level 3, but with the GUI, X Window System, running.
6Reboot. Entering this run level reboots Linux.

Changing Run Levels

The run level can be changed by using either the init or telinit commands. If Linux is currently running in run level 5 and you want to change to run level 3, issue the command init 3 or telinit 3. You can also set the “initdefault” parameter in /etc/inittab to whatever runlevel you want your computer to enter each time it boots.

You should never set the default run level in the inittab file to either run level 0 or run level 6. Your computer would either shut down every time you tried to start it or continuously reboot.


The init program is a binary (ELF) executable file and it is the mother of all processes. It is always Process ID (PID) 1. Red Hat calls this the First Process. The init program is really the end of the boot process and the beginning of the startup.

The init program runs the /etc/rc.d/rc.sysinit script and uses the /etc/inittab file to determine the startup configuration for Linux. It then runs the /etc/rc.d/rc script which checks /etc/inittab for the default runlevel.

The /etc/inittab file also contains  system initialization script name (rc.sysinit) and and the GETTYs for the virtual consoles. A getty (Get TTY) is a process that waits for a virtual console login and, when a login is successful, connects the logged in user to a terminal session and shell.

All of these startup files are BASH scripts that can be viewed so that you can see exactly what actions are performed during the Startup sequence. You should do so at some point as it is a very interesting exercise. You should never change these scripts, however. There are other, much better ways of modifying the Startup sequence that fall completely within the standard best practices.

The Startup process is governed by the configuration specified in the /etc/inittab (initialization table) file. The inittab file contains configuration items that specify several important aspects of the startup process. These include the following items:

Note: As of Fedora 11, the inittab file is used only to specify the default runlevel. All of the other functions have been replaced by the new upstart Startup manager. However, starting with Fedora 14, upstart was replaced by systemd and the inittab file is no longer used at all. What is left is merely a stub to indicate that it is no longer used.
  • The default runlevel
  • The name and location of the system initialization script
  • The directories containing the runlevel scripts
  • Traps for key sequences such as ctrl-alt-delete
  • UPS power failure and restore scripts
  • GETTY definitions

A typical inittab file looks like this:

# inittab       This file describes how the INIT process should set up
#               the system in a certain run-level.
# Author:       Miquel van Smoorenburg, <>
#               Modified for RHS Linux by Marc Ewing and Donnie Barne
# Default runlevel. The runlevels used by RHS are:
#   0 – halt (Do NOT set initdefault to this)
#   1 – Single user mode
#   2 – Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 – Full multiuser mode
#   4 – unused
#   5 – X11
#   6 – reboot (Do NOT set initdefault to this)
# System initialization.
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 “Power Failure; System Shutting Down”
# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c “Power Restored; Shutdown Cancelled”
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon

Default Runlevel

The default runlevel is defined by the line:


This specifies that the default is runlevel 5, which is graphical mode. Typical default run levels are 3 and 5. Refer to Understanding Run Levels for more information.

System Initialization Program

The following line specifies the system initialization program. In this case, the script /etc/rc.d/rc.sysinit.


The rc.sysinit script performs many important functions including activating SELinux, if it is configured, enabling swap partitions, activating RAID and Logical Volume Manager devices and disk quotas. It also checks and mounts the other filesystems.

The leading “si” is merely an identifier. The third field is the action field and contains “sysinit” which specifies the purpose of the line, and the rest of the line is the fully qualified path and file name.

Run Level Descriptors

The next several lines define the run levels and the locations of the start scripts for each run level.

l0:0:wait:/etc/rc.d/rc 0 
l1:1:wait:/etc/rc.d/rc 1 
l2:2:wait:/etc/rc.d/rc 2 
l3:3:wait:/etc/rc.d/rc 3 
l4:4:wait:/etc/rc.d/rc 4 
l5:5:wait:/etc/rc.d/rc 5 
l6:6:wait:/etc/rc.d/rc 6

Again, the first column is a text identifier. The second column is the number of the run level. The fourth column is the path and filename of the script that runs the start scripts with the numeric parameter representing the run level.

The action field in these lines is “wait” which means that init launches the process once and then waits for it to complete before continuing.


Traps allow init to capture certain actions and react in specific ways to them.


ca::ctrlaltdel:/sbin/shutdown -t3 -r now

This first line traps the Ctrl-Alt-Del key combination and reboots the computer after waiting 3 seconds. This allows Linux to react to Ctrl-Alt-Del in the same way as other operating systems. If you do not want your computer to respond to Ctrl-Alt-Del in this way, you can change the action field of this line.

Power Failure

The init process can react to a power failure as well. This assumes that the computer is connected to a UPS and that the computer is running software which communicates with the UPS and understands when a power failure has occurred. I use the Open Source APCUPSD program for communicating with my APC UPS’es.

pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down" pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Canceled"

The first of these two lines shuts down the system to a complete halt and power off after a wait of two minutes. The second cancels the shutdown if power returns during the 2 minute wait. The text in the quotes is displayed on every terminal to all users so that they can be forewarned.

The gettys

A getty is a process that waits for a login connection on a text mode “tty.” When a login connection is made, the getty turns over control of the virtual terminal to a terminal session and the shell running in it. When the user of the session logs out, the shell and terminal session are terminated and init respawns a new getty to wait for the next connection.

1:2345:respawn:/sbin/mingetty tty1 
2:2345:respawn:/sbin/mingetty tty2 
3:2345:respawn:/sbin/mingetty tty3 
4:2345:respawn:/sbin/mingetty tty4 
5:2345:respawn:/sbin/mingetty tty5 
6:2345:respawn:/sbin/mingetty tty6

Each of the gettys defined in the lines above waits on one of the text mode virtual terminals for a login. The second field specifies that the getty is to run in run levels 2 through 5.

Use the key combination Ctrl-Alt-FX, where X is a number from 1 to 6, to switch your Linux screen to one of the virtual terminal login sessions. Depending upon which release of Fedora you are using, terminals 1 or 7 may be your GUI.

They term “getty” is a historical one that literally means “get tty” or “get teletype.” When Unix was in its heyday, a teletype was the standard way to connect to a computer.


The final line in inttab is the line that specifies the X (the X Window System) login program for run level 5.

x:5:respawn:/etc/X11/prefdm -nodaemon

This works in very much the same way that the getty lines do for text mode logins. The prefdm program is run and launches a default program for a graphical login. This graphical login program waits for a login and turns over control to X. The init program waits until the user logs out and then respawns another copy of the prefdm program, which in turn launches the default graphical login program to wait for another login.


The /etc/rc.d/rc.sysinit script performs many tasks to initialize Linux. rc.sysinit is run by init and is the first step of the startup process. The tasks performed by rc.sysinit include:

  • Sets the hostname.
  • Mounts the proc and system filesystems.
  • Activates SELinux if it is set to enforcing or permissive.
  • Initializes hardware using modprobe to load device drivers.
  • Starting the udev device manager.
  • Sets kernel parameters as defined in /etc/sysctl.conf.
  • Starts RAID arrays and device mapper for LVM devices.
  • Checks the root filesystem and remounts it as read/write.
  • Enables disk quotas if they are defined.
  • Forces fsck to run if the system was shut down uncleanly or if a filesystem has exceeded the time or number of mounts since it was last checked.
  • Mounts the other filesystems defined in /etc/fstab.
  • Starts swapping.
  • Dumps the current contents of the syslog ring buffer into /var/log/dmesg so it will be available later.

As mentioned above rc.sysinit is a script, written in BASH, and that allows you to look at it and analyze the tasks it performs. I suggest that you do so in order to fully understand this part of the startup sequence.


The /etc/rc.d/rc script is the last major step in the startup process. The rc script initializes the run level defined in the /etc/inittab file by running the scripts located in the directory for that run level, i.e., /etc/rc.d/rc3.d for run level 3.

The rc script is fairly short. It first verifies that a valid run level has been passed to it. It runs all of the Kill scripts in that run level and then runs all of the Start scripts in that run level.

Leave a Reply