Understanding The Linux Init Process & Different RunLevels

Different Linux systems can be used in many ways. This is the main idea behind operating different services at different operating levels. For example, the Graphical User Interface can only be run if the system is running the X-server; multiuser operation is only possible if the system is in a multiuser state or mode, such as having networking available. These are the higher states of the system, and sometimes you may want to operate at a lower level, say, in the single user mode or the command line mode.

Such levels are important for different operations, such as for fixing file or disk corruption problems, or for the server to operate in a run level where the X-session is not required. In such cases having services running that depend on higher levels of operation, makes no sense, since they will hamper the operation of the entire system.

Each service is assigned to start whenever its run level is reached. Therefore, when you ensure the startup process is orderly, and you change the mode of the machine, you do not need to bother about which service to manually start or stop.

The main run-levels that a system could use are:

RunLevel	Target	Notes
0	runlevel0.target, poweroff.target	Halt the system
1	runlevel1.target,  rescue.target	Single user mode
2, 4	runlevel2.target, runlevel4.target, multi-user.target	User-defined/Site-specific runlevels. By default, identical to 3
3	runlevel3.target,multi-user.target	Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5	runlevel5.target, graphical.target	Multi-user, graphical. Usually has all the services of runlevel3 plus a graphical login - X11
6	runlevel6.target, reboot.target	Reboot
Emergency	emergency.target	Emergency shell

The system and service manager for Linux is now “systemd”. It provides a concept of “targets”, as in the table above. Although targets serve a similar purpose as runlevels, they act somewhat differently. Each target has a name instead of a number and serves a specific purpose. Some targets may be implemented after inheriting all the services of another target and adding more services to it.

Backward compatibility exists, so switching targets using familiar telinit RUNLEVEL command still works. On Fedora installs, runlevels 0, 1, 3, 5 and 6 have an exact mapping with specific systemd targets. However, user-defined runlevels such as 2 and 4 are not mapped that way. They are treated similar to runlevel 3, by default.

For using the user-defined levels 2 and 4, new systemd targets have to be defined that makes use of one of the existing runlevels as a base. Services that you want to enable have to be symlinked into that directory.

The most commonly used runlevels in a currently running linux box are 3 and 5. You can change runlevels in many ways.
A runlevel of 5 will take you to GUI enabled login prompt interface and desktop operations. Normally by default installation, this would take your to GNOME or KDE linux environment. A runlevel of 3 would boot your linux box to terminal mode (non-X) linux box and drop you to a terminal login prompt. Runlevels 0 and 6 are runlevels for halting or rebooting your linux respectively.

Although compatible with SysV and LSB init scripts, systemd:

• Provides aggressive parallelization capabilities.
• Offers on-demand starting of daemons.
• Uses socket and D-Bus activation for starting services.
• Keeps track of processes using Linux cgroups.
• Maintains mount and automount points.
• Supports snapshotting and restoring of the system state.
• Implements an elaborate transactional dependency-based service control logic.

Systemd starts up and supervises the entire operation of the system. It is based on the notion of units. These are composed of a name, and a type as shown in the table above. There is a matching configuration file with the same name and type. For example, a unit avahi.service will have a configuration file with an identical name, and will be a unit that encapsulates the Avahi daemon. There are seven different types of units, namely, service, socket, device, mount, automount, target, and snapshot.

To introspect and or control the state of the system and service manager under systemd, the main tool or command is “systemctl”. When booting up, systemd activates the default.target. The job of the default.target is to activate the different services and other units by considering their dependencies. The ‘system.unit=’ command line option parses arguments to the kernel to override the unit to be activated. For example,

systemd.unit=rescue.target is a special target unit for setting up the base system and a rescue shell (similar to run level 1);

systemd.unit=emergency.target, is very similar to passing init=/bin/sh but with the option to boot the full system from there;

systemd.unit=multi-user.target for setting up a non-graphical multi-user system;

systemd.unit=graphical.target for setting up a graphical login screen.

How to Enable/Disable Linux Services

Following are the commands used to enable or disable services in CentOS, Redhat Enterprise Linux and Fedora systems:

Activate a service immediately e.g postfix:

[root@gateway ~]# service postfix start
Starting postfix: [  OK  ]

To deactivate a service immediately e.g postfix:

[root@gateway ~]# service postfix stop
Shutting down postfix: [  OK  ]

To restart a service immediately e.g postfix:

[root@gateway ~]# service postfix restart
Shutting down postfix: [FAILED]
Starting postfix: [  OK  ]

You might have noticed the 'FAILED' message. This is normal behavior as we shut down the postfix service with our first command (service postfix stop), so shutting it down a second time would naturally fail!

Determine which Linux Services are Enabled at Boot

 The first column of this output is the name of a service which is currently enabled at boot. Review each listed service to determine whether it can be disabled.
 If it is appropriate to disable a service , do so using the command:

[root@gateway ~]# chkconfig -level servicename off

Run the following command to obtain a list of all services programmed to run in the different Run Levels of your system:

[root@gateway ~]#  chkconfig --list | grep :on

NetworkManager  0:off   1:off   2:on    3:on    4:on    5:on    6:off
abrtd           0:off   1:off   2:off   3:on    4:off   5:on    6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:on    4:on    5:on    6:off
autofs          0:off   1:off   2:off   3:on    4:on    5:on    6:off
avahi-daemon    0:off   1:off   2:off   3:on    4:on    5:on    6:off
cpuspeed        0:off   1:on    2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
cups            0:off   1:off   2:on    3:on    4:on    5:on    6:off
haldaemon       0:off   1:off   2:off   3:on    4:on    5:on    6:off
httpd           0:off   1:off   2:off   3:on    4:off   5:off   6:off
ip6tables       0:off   1:off   2:on    3:on    4:on    5:on    6:off
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off

Several of these services are required, but several others might not serve any purpose in your environment, and use CPU and memory resources that would be better allocated to applications. Assuming you don't RPC services, autofs or NFS, they can be disabled for all Run Levels using the following commands:

[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 nfslock off
[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 netfs off
[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 rpcgssd off
[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 rpcidmapd off
[root@gateway ~]# /sbin/chkconfig –level 0123456 portmap off
[root@gateway ~]# /sbin/chkconfig –level 0123456 autofs off

How to Change Runlevels

You can switch to runlevel 3 by running:    

[root@gateway ~]# systemctl isolate multi-user.target

(or)

[root@gateway ~]# systemctl isolate runlevel3.target

You can switch to runlevel 5 by running:    

[root@gateway ~]# systemctl isolate graphical.target

(or)

[root@gateway ~]# systemctl isolate runlevel5.target

 

How to Change the Default Runlevel using Systemd

The systemd uses symlinks to point to the default runlevel. You have to delete the existing symlink first, before you can create a new one:    [root@gateway ~]# rm /etc/systemd/system/default.target

Switch to runlevel 3 by default:

[root@gateway ~]# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target  

Switch to runlevel 5 by default:    

[root@gateway ~]# ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

And just in case you were wondering, systemd does not use the classic /etc/inittab file.

 

How to Change the Default Runlevel using the Inittab file

There's the Systemd way and of course, the Inittab way. In this case, Runlevels are represented by /etc/inittab text file. The default runlevel is always specified from /etc/inittab text file.
To change the default runlevel in fedora ,edit /etc/inittab and find the line that looks like this:  id:5:initdefault:
The number 5 represents a runlevel with X enabled (GNOME/KDE mostly). If you want to change to runlevel 3, simply change this

id:5:initdefault:
to this

id:3:initdefault:
Save and reboot your linux box. Your linux box would now reboot on runlevel 3, a runlevel without X or GUI. Avoid changing the default /etc/iniittab runlevel value to 0 or 6 .