Red Hat Certified System Administration 8

Chapter 11: Working with Systemd

Goal

• Control and monitor network services and system daemons using systemd.
• Start and stop services and configure services to start automatically at boot.

Sommaire

Systemd
Runlevels
Services
Systemd Units
Systemctl

Systemd

systemd

System startup and server processes are managed by the systemd System and Service Manager.

Daemons are processes that wait or run in the background performing various tasks.
Generally, daemons start automatically at boot time and continue to run until shutdown or until they are manually stopped.
By convention, the names of many daemon programs end in the letter "d".

To listen for connections, a daemon uses a socket. This is the primary communication channel with local or remote clients.

A bit of history

For many years, process ID1 of Linux and UNIX systems has been the init process.
This process Was responsible for activating other services on the system and is the origin of the term "init system."
Frequently used daemons were started on systems at boot time with SystemV and LSB init scripts.
These are shell scripts, and may vary from one distribution to another.
Less frequently used daemons were started on demand by another service, such as initd or xinetd, which listens for client connections.
These systems have sever all imitations, which are addressed with systemd.

In Red Hat Enterprise Linux 7, process ID1 is systemd, the new init system. A few of the new Features provided by system include:
•Parallelization capabilities, which increase the boot speed of a system.
•On-demand starting of daemons without requiring a separate service.
•Automatic service dependency management, which can prevent long timeouts, such as by not Starting a network service when the network is not available.
•A method of tracking related processes together by using Linux control groups.

Runlevels

Each runlevel also has a directory called /etc/rc.d/rc#.d, where # is the runlevel (from 0 to 6). These different directories contain scripts to tell the system which services should be started or stopped at the particular runlevel.

Commands

[root@redhat ~]# init runlevel restart system in a runlevel
[root@redhat ~]# runlevel show current runlevel
[root@redhat ~]# who -r show current runlevel

running levels

0 Halt
1 Single-user mode
2 Multiuser with partial services
3 Full multiuser with networking (text mode)
4 Not used
5 Full multiuser graphical mode (provides a GUI desktop login)
6 Reboot

Services

Usual Services List

httpd web server
firewalld firewall
NetworkManager.service Networking
vsftpd ftp service
mysqld Mysql server
sshd SSH server

Systemd Units

The systemctl command is used to manage different types of system objects, called units.
A list of available unit types can be displayed with [root@redhat ~]# systemctl -t help.

Service units have a.service extension and represent system services. This type of unit is used to start frequently accessed daemons, such as a webserver.
Socket units have a.socket extension and represent inter-process communication(IPC) sockets. Control of the socket will be passed to a daemon or newly started service when a client connection is made. Socket units are used to delay the start of a service at boot time and to start less frequently used services on demand. These are similar in principle to services which use the xinetd super server to start on demand.
Path units have a.path extension and are used to delay the activation of a service until a specific file system change occurs. This is commonly used for services which uses pool directories, such as a printing system.

Service units have a .service extension
Socket units have a .socket extension
Path units have a .path extension

Probably the most important unit type is the service unit. It is used to start processes. You can start any type of process by using a service unit, including daemon processes and commands.

Understanding Systemd Unit Locations

The major benefit of working with Systemd, as compared to previous methods Red Hat used for managing services, is that it provides a uniform interface to start units. This interface is defined in the unit file. Unit files can occur in three locations:

• /usr/lib/systemd/system contains default unit files that have been installed from RPM packages. You should never edit these files directly.

• /etc/systemd/system contains custom unit files. It may also contain files that have been written by an administrator or generated by the systemctl edit command.

• /run/systemd/system contains unit files that have automatically been generated.

If a unit file exists in more than one of these locations, units in the /run directory have highest precedence and will overwrite any settings that were defined elsewhere. Units in /etc/systemd/system have second highest precedence, and units in /usr/lib/systemd/system come last.

Systemctl

systemctl Tool

systemctl is the tool used by Systemd to manage Units

Syntax

[root@redhat student]# systemctl option service.unit

Service states

Loaded	Unit configuration file has been processed.
active(running)	Running with one or more continuing processes.
active(exited)	Successfully completed a one-time configuration.
active(waiting)	Running but waiting for an event.
Inactive	Not running.
Enabled	Will be started at boot time.
Disabled	Will not be started at boot time.
Static	Cannot be enabled, but may be started by an enabled unit automatically.

Enable or Disable a service

Make enable state for a service configure that service to boot at OS Boot time. It will be done by
[root@redhat ~]# systemctl enable service-name

This command make a symbolic link of Service Unit File in /etc/systemd/system/multi-user.target.wants/ directory

Commands

[root@localhost student]# systemctl -t help list of available unit types
[root@localhost student]# systemctl Query the state of all units to verify a system startup
[root@localhost student]# systemctl status sshd.service
[root@localhost student]# systemctl -l status sshd.service display full infos or
[root@localhost student]# systemctl status sshd.service -l display full infos
[root@localhost student]# systemctl --type=service Query the state of only the service units.
[root@localhost student]# systemctl --type=socket Query the state of only the sockets units.
[root@localhost student]# systemctl disable sshd.service Disable SSHD service
[root@localhost student]# systemctl enable sshd.service Enable SSHD Service
[root@localhost student]# systemctl list-dependencies UNIT List units which are required and wanted by the specified unit.

[root@redhat ~]# systemctl list-units --type service --state active Active Services List

Masking Services

At times, a system may have conflicting services installed. For example, there are multiple methods to manage networks
(network and Network Manager) and firewalls (iptables and firewalld).
To prevent an administrator from accidentally starting a service, that service may be masked.
Masking will create a link in the configuration directories so that if the service is started, nothing will happen.

NB:
■ A disabled service will not be started automatically at boot or by other unit files, but can be started manually.
■ A masked service cannot be started manually or automatically.

Example
[root@localhost student]# systemctl mask network Masking Network Service
[root@localhost student]# systemctl unmask network Unmasking Network Service

Power Management Commands with systemctl

[root@lab ~]# systemctl halt Halts the system.(Old Command halt)
[root@lab ~]# systemctl poweroff Powers off the system. Old Command poweroff
[root@lab ~]# systemctl reboot Restarts the system. Old Command reboot
[root@lab ~]# systemctl suspend Suspends the system. Old Command pm-suspend
[root@lab ~]# systemctl hibernate Hibernates the system. Old Command pm-hibernate
[root@lab ~]# systemctl hybrid-sleep Hibernates and suspends the system. Old Command pm-suspend-hybrid

Eninam BAGNABANA | | bagnadavid@outlook.fr |