|Understanding The Linux Init Process & Different RunLevels|
|Written by Administrator|
|Friday, 24 February 2012 01:40|
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:
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:
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 stopTo restart a service immediately e.g postfix:
Shutting down postfix: [ OK ]
[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:
Run the following command to obtain a list of all services programmed to run in the different Run Levels of your system:
How to Change Runlevels
You can switch to 'runlevel 3' by running:
[root@gateway ~]# systemctl isolate multi-user.target
[root@gateway ~]# systemctl isolate runlevel3.target
You can switch to 'runlevel 5' by running:
[root@gateway ~]# systemctl isolate graphical.target
[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
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 .
|Last Updated on Friday, 24 February 2012 15:37|