Chapter 4. Init : SystemV, Upstart, Systemd
When a Linux system start up, many tasks have to be accomplished in a cooperative fashion.
- Devices have to be recognized and initialized
- System services have to be launched
- Filesystems have to be made available
- Important management processes have to start
- System must be made available for users to login
All this has to be done in the right sequence and as quickly as possible
OBJECTIVES
- Understand the importance of the init process.
- Explain how the traditional SysVinit method works and how it incorporates runlevels and what happens in each one.
- Know how to use chkconfig and services (and alternative utilities) to start and stop services or make them persistent across reboots.
- Understand why the alternative Upstart and systemd methods arose and how they work.
- Use systemctl to configure and control systemd.
THE INIT PROCESS
/sbin/init
Usually called just init is the main process of the operating system due to its role while orchestrating all the necesary tasks that needs to be accomplished to start and mantain the systems.
This process starts with the boot and finishes with the system's shut down.
Traditionaly nearly all linux distributions based the init process on Unix's venerable SysVinit, such process is old and is not efficient since it was designed for :
- Multi user mainframe systems (not personal computers)
- Target was a single processor system
- Startup (and shutdown) time was not an important matter
STARTUP ALTERNATIVES
Upstart and systemd are both alternatives, nevertheless the wind is blowing in favor to systemd which has a community of developers closely related to the linux kernel development team
within the next section, we will consider SysVinit and systemd methods.
SysVinit work with runleves, which are a sort of possible stages for the system to be in, for example
Runlevel 0 is reserved for the system halt state
Runlevel 1 is reserved for single-user mode
Runlevel 6 is reserved for system reboot
The other Runlevels varies depending on the Linux distribution, for example on Red Hat based systems we have
Runlevel 2 is defined as a runing system without networking or X
Runlevel 3 is defined as a runing system with networking but without X
Runlevel 5 includes networking and X
runlevel comand
$ runlevel N 5
Tells you in which runlevel the system is running on, in this case comes from N (Unknown) to 5
telinit command
$ sudo /sbin/telinit 5
Takes the systems to a defined runlevel, in this case to the runlevel 5
Table 4.1. System Runlevels
| Runlevel | Meaning |
|---|---|
| S,s | Same as 1 |
| 0 | Shutdown system and turn power off |
| 1 | Single User Mode |
| 2 | Multiple user, no NFS, only text login |
| 3 | Multiple user, with NFS and network, only text login |
| 4 | Not used |
| 5 | Multiple user, with NFS and network, graphical login with X |
| 6 | Reboot |
SYSVINIT AND /etc/inittab
The file that tells the init process which operations to execute at which runlevel is the inittab file, such file can describe an action like this
id : runleve(s) : action : process
Where
id is a four digit identification for the entry
runlevel(s) zero or more single digits indicating the runlevel
action describes the action to be taken
process specifies the process to be executed
SYSVINIT STARTUP SCRIPTS
These are the scripts specified to run depending on the runlevel, usually located at
/etc/rc.d
This directory contains a list of each one of folders that contains the scripts to be runned for each runlevel as
[root@localhost rc.d]# pwd /etc/rc.d [root@localhost rc.d]# ll total 32 drwxr-xr-x. 2 root root 4096 oct 29 18:29 init.d drwxr-xr-x. 2 root root 4096 oct 29 18:29 rc0.d drwxr-xr-x. 2 root root 4096 oct 29 18:29 rc1.d drwxr-xr-x. 2 root root 4096 oct 29 18:29 rc2.d drwxr-xr-x. 2 root root 4096 oct 29 18:29 rc3.d drwxr-xr-x. 2 root root 4096 oct 29 18:29 rc4.d drwxr-xr-x. 2 root root 4096 oct 29 18:29 rc5.d drwxr-xr-x. 2 root root 4096 oct 29 18:29 rc6.d
Within each one directory we have things like this
[root@localhost rc.d]# cd rc0.d/ [root@localhost rc0.d]# ll total 0 lrwxrwxrwx. 1 root root 22 oct 29 18:29 K01livesys-late -> ../init.d/livesys-late lrwxrwxrwx. 1 root root 20 oct 29 18:23 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 17 oct 29 18:23 K90network -> ../init.d/network lrwxrwxrwx. 1 root root 17 oct 29 18:29 K99livesys -> ../init.d/livesys
CHKCONFIG
This command is useful to configure the scripts that will run at certain runlevel, some samples for this command
chkconfig Examples
Check a particular service to see if it is set up to run in the the current runlevel:
$ chkconfig some_service
This will return true if the service is configured to be running, false otherwise. You should note that even if it is configured to be running, it might currently be stopped.
See what services are configured to run in each of the runlevels:
$ chkconfig --list [service names]
Turn on a certain service next time the system boots:
$ sudo chkconfig some_service on
Do not turn a certain service on next time the system boots:
$ chkconfig some_service off
You should note that the on and off do not affect the current state by starting or stopping a service. You would have to do that with:
$ sudo service some_service [ stop | start ]
TO ADD YOUR OWN STARTUP SCRIPTS
We must place them within
$ /etc/init.d
CHKCONFIG SCRIPTS CONFIGURATION
How does chkconfig actually determine which number should appear after the S or K in a symbolic link, and how does it know which runlevels to set on or off and what state to set the symbolic links in? The information is in the scripts themselves, which contain a line near the top like:
# chkconfig: 2345 10 90
The first argument after the chkconfig: is there to define which runlevels to have the service on by default. In the above example that means levels 2, 3, 4 and 5.
The second and third numbers are the numerical prefixes in the start and stop scripts, so in the above they start with S10 and K90
SERVICE
Operative systems require services that usually start at boot time and remain alive until shut down (not necessarily). Such services are in this directory
$ /etc/init.d/
In order to check the status of a certain service
- network service
$ sudo service network status Configured devices: lo eth0 eth1 eth2 wlan0 Currently active devices: lo eth0
- vsftpd service
$ sudo service vsftpd status vsftpd (pid 5284) is running...
Parameters
The service command takes a different set of parameter, according to the service, for example
$ sudo service network
Usage: /etc/init.d/network {start|stop|restart|reload|status}
$ sudo service iptables
Usage: /etc/init.d/iptables {start|stop|restart|condrestart|status|panic|save}
Status
In order to check the status of all the services execute the next command
[abernal@localhost ~]$ sudo service --status-all [sudo] password for abernal: el módulo netconsole no se cargó Dispositivos configurados: lo enp0s3 virbr0-nic Dispositivos activos en el momento: lo enp0s3 virbr0
UPSTART
The upstart configuration files are:
/etc/init/rcS.conF /etc/rc-sysinit.conf /etc/inittab /etc/init/rc.conf /etc/rc[0-6].d
Using initctl you can view, start, stop jobs in much the same way that service does. The syntax is:
$ initctl options command
where options can have the following values:
start: Starts a job
stop: Stops a job
restart Restarts a job
reload Sends HUP signal to a job
status Queries status of a job
list: List known jobs
emit Emits an event
For more reference please visit this site
SYSTEMD
This is a system and session manager, it is backward compatible with SysVinit and the concept of runlevels is supported via runlevel targets. For example the telinit program is emulated to work with runlevels
Features
- Is compatible with SysVinit scripts.
- Boots faster than previous systems.
- Provides aggressive parallelization capabilities.
- Uses socket and D-Bus activation for starting services.
- Replaces shell scripts with programs.
- Offers on-demand starting of daemons.
- Keeps track of processes using cgroups.
- Supports creating snapshots and restoring of the system state.
- Maintains mount and automount points.
- Implements an elaborate transactional dependency-based service control logic.
- Can work as a drop-in replacement for SysVinit
Instead of bash scripts, systemd uses .service files. In addition, systemd sorts all daemons into their own Linux cgroups (control groups).
Configuration files
- /etc/hostname
- /etc/vconsole.conf: default keyboard mapping and console font.
- /etc/sysctl.d/*.conf: drop-in directory for kernel sysctl parameters.
- /etc/os-release: distribution ID file.
Systemctl
Main utility to manage services, its basic syntax is
$ systemctl [options] command [name]
Examples
Below you can see some examples of how you can use systemctl
To show the status of everything that systemd controls:
$ systemctl
To show all available services:
$ systemctl list-units -t service --all
To show only active services:
$ systemctl list-units -t service
To start (activate) one or more units:
$ sudo systemctl start foo $ sudo systemctl start foo.service $ sudo systemctl start /path/to/foo.service
where a unit can be a service or a socket.
To stop (deactivate):
$ sudo systemctl stop foo.service
To enable/disable a service:
$ sudo systemctl enable sshd.service
$ sudo systemctl disable sshd.service
This is the equivalent of chkconfig --add/--del and doesn't actually start the service.
Note: some systemctl commands in the above can be run as non-root user, others require running as root or with sudo.
Reference
For more information visit this site
LAB 1
Lab 4.1: Adding a New Startup Service with SysVinit
In this and the following exercise, we will create a simple startup service. First we will do it for a SysVinit system. Note that if you are using a systemd-based system everything should still work because of the backwards compatibility layer that all distributions utilize. However, in the next exercise we will do natively for systemd.
If you are on a Debian-based system like Ubuntu, make sure you have installed the sysvinit-utils and chkconfig packages. However, recent versions of Ubuntu no longer package chkconfig; you’ll have to use the update-rc.d utility instead.
First we have to create the service-specific script; you can create one of your own for fun, or to get the procedure down just (as root) create a file named /etc/init.d/fake_service containing the following content:
#!/bin/bash
# fake_service
# Starts up, writes to a dummy file, and exits
#
# chkconfig: 35 69 31
# description: This service doesn’t do anything.
# Source function library
. /etc/sysconfig/fake_service
case "$1" in
start) echo "Running fake_service in start mode..."
touch /var/lock/subsys/fake_service
echo "$0 start at $(date)" >> /var/log/fake_service.log
if [ ${VAR1} = "true" ]
then
echo "VAR1 set to true" >> /var/log/fake_service.log
fi
echo
;; stop)
echo "Running the fake_service script in stop mode..."
echo "$0 stop at $(date)" >> /var/log/fake_service.log
if [ ${VAR2} = "true" ]
then
echo "VAR2 = true" >> /var/log/fake_service.log
fi
rm -f /var/lock/subsys/fake_service
echo
;;
*)
echo "Usage: fake_service {start | stop}"
exit 1
esac exit 0Make the file above executable and give other proper permissions:
$ sudo chmod 755 /etc/init.d/fake_service
You’ll notice the script includes the file /etc/sysconfig/fake service. (On non-RHEL systems you should change this to /etc/default/fake_service.) Create it and give it the following contents:
VAR1="true"
VAR2="true"
Test to see if the script works properly by running the following commands:
$ sudo service fake_service
$ sudo service fake_service start
$ sudo service fake_service stop
Look at the file named /var/log/fake service.log. What does it contain?
For fun you can add additional modes like restart to the script file; look at other scripts in the directory to get examples of what to do.
Next we will want to have the ability to start fake service whenever the system starts, and stop it when it shuts down.
If you do:
$ sudo chkconfig --list fake_service
you will get an error as it hasn’t been set up yet for this. You can easily do this with:
$ sudo chkconfig --add fake_service
and you can turn it on or off at boot time with
$ sudo chkconfig fake_service on $ sudo chkconfig fake_service off
To test this completely you’ll have to reboot the system to see if it comes on automatically. You can also try varying the runlevels in which the service is running.
LAB 2
Lab 4.2: Adding a New Startup Service with systemd
As mentioned in the previous exercise, you can still use the SysVinit startup script procedure with systemd but this is deprecated. The analagous procedure is to create (as root) a file directly under /etc/systemd/system or somewhere else in that directory tree; distributions have some varying tastes on this. For example a very minimal file named /etc/systemd/system/fake2.service:
[Unit] Description=fake2 After=network.target [Service] ExecStart=/bin/echo I am starting the fake2 service ExecStop=/bin/echo I am stopping the fake2 service [Install] WantedBy=multi-user.target
Now there are many things that can go in this unit file. The After=network.target means the service should start only after the network does, while the WantedBy=multi-user.target means it should start when we reach multiple-user mode. This is equivalent to runlevels 2 and 3 in SysVinit. Note graphical.target would correlate with runlevel 5.
Change the permissions on the file to make it executable:
$ chmod 755 /etc/systemd/system/fake2.service
Now all we have to do to start, stop and check the service status are to issue the commands:
$ sudo systemctl start fake2.service $ sudo systemctl status fake2.service $ sudo systemctl stop fake2.service
If you are fiddling with the unit file while doing this you’ll need to reload things with:
$ sudo systemctl daemon-reload
as the system will warn you.
To set things up so the service turns on or off on system boot:
$ sudo systemctl enable fake2.service $ sudo systemctl disable fake2.service
Once again, you really need to reboot to make sure it has taken effect.