Show
10.1. Introduction to systemdSystemd is a system and service manager for Linux operating systems. It is designed to be backwards compatible with SysV init scripts, and provides a number of features such as parallel startup of system services at boot time, on-demand activation of daemons, or dependency-based service control logic. In Red Hat Enterprise Linux 7, systemd replaces Upstart as the default init system. Systemd introduces the concept of systemd units. These units are represented by unit configuration files located in one of the directories listed in Table 10.2, “Systemd Unit Files Locations”, and encapsulate information about system services, listening sockets, and other objects that are relevant to the init system. For a complete list of available systemd unit types, see Table 10.1, “Available systemd Unit Types”. Table 10.1. Available systemd Unit Types
Table 10.2. Systemd Unit Files Locations
Overriding the Default systemd Configuration Using system.conf The default configuration of systemd is defined during the compilation and it can be found in systemd configuration file at For example, to override the default value of the
timeout limit, which is set to 90 seconds, use the DefaultTimeoutStartSec=required value See also Example 10.21, “Changing the timeout limit”. 10.1.1. Main FeaturesIn Red Hat Enterprise Linux 7, the systemd system and service manager provides the following main features:
10.1.2. Compatibility ChangesThe systemd system and service manager is designed to be mostly compatible with SysV init and Upstart. The following are the most notable compatibility changes with regards to the previous major release of the Red Hat Enterprise Linux system:
For a detailed list of compatibility changes introduced with systemd, see the Migration Planning Guide for Red Hat Enterprise Linux 7. 10.2. Managing System Services Previous versions of Red Hat Enterprise Linux, which were distributed with SysV init or Upstart, used init scripts located in the
Service units end with the Table 10.3. Comparison of the service Utility with systemctl
Table 10.4. Comparison of the chkconfig Utility with systemctl
Specifying Service Units For clarity, all command examples in the rest of this section use full unit names with the ~]# systemctl stop nfs-server.service However, the file extension can be omitted, in which case the ~]# systemctl stop nfs-server Additionally, some units have alias names. Those names can have shorter names than units, which can be used instead of the actual unit names. To find all aliases that can be used for a particular unit, use: ~]# systemctl show nfs-server.service -p Names Behavior of systemctl in a chroot Environment If you change the root directory using the The exception to this are unit file commands such as the ~]# chroot /srv/website1 ~]# systemctl enable httpd.service Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service, pointing to /usr/lib/systemd/system/httpd.service. 10.2.1. Listing ServicesTo list all currently loaded service units, type the following at a shell prompt:
For each service unit file, this command displays its full name ( By default,
the
You can also list all available service units to see if they are enabled. To do so, type:
For each service unit, this command displays its full name ( Example 10.1. Listing Services To list all currently loaded service units, run the following command: ~]$ To list all installed service unit files to determine if they are enabled, type: ~]$ systemctl list-unit-files --type service UNIT FILE STATE abrt-ccpp.service enabled abrt-oops.service enabled abrt-vmcore.service enabled abrt-xorg.service enabled abrtd.service enabled ... wpa_supplicant.service disabled ypbind.service disabled 208 unit files listed. 10.2.2. Displaying Service StatusTo display detailed information about a service unit that corresponds to a system service, type the following at a shell prompt:
Replace
name with the name of the service unit you want to inspect (for example, Table 10.5. Available Service Unit Information
To only verify that a particular service unit is running, run the following command:
Similarly, to determine whether a particular service unit is enabled, type:
Note that both Example 10.2. Displaying Service Status The service unit for the GNOME Display Manager is named
~]# systemctl status gdm.service gdm.service - GNOME Display Manager Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled) Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago Main PID: 1029 (gdm) CGroup: /system.slice/gdm.service ├─1029 /usr/sbin/gdm ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno... └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r... Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager. Example 10.3. Displaying Services Ordered to Start Before a Service To determine what services are ordered to start before the specified service, type the following at a shell prompt: ~]# systemctl list-dependencies --after gdm.service gdm.service ├─dbus.socket ├─ ├─livesys.service ├─plymouth-quit.service ├─system.slice ├─systemd-journald.socket ├─systemd-user-sessions.service └─basic.target [output truncated] Example 10.4. Displaying Services Ordered to Start After a Service To determine what services are ordered to start after the specified service, type the following at a shell prompt: ~]# systemctl list-dependencies --before gdm.service gdm.service ├─dracut-shutdown.service ├─graphical.target │ ├─systemd-readahead-done.service │ ├─systemd-readahead-done.timer │ └─systemd-update-utmp-runlevel.service └─shutdown.target ├─systemd-reboot.service └─final.target └─systemd-reboot.service 10.2.3. Starting a Service To start a service unit that corresponds
to a system service, type the following at a shell prompt as
Replace name with the name of the service unit you want to start (for example, Example 10.5. Starting a Service The service unit for the Apache HTTP Server
is named ~]# systemctl start httpd.service 10.2.4. Stopping a Service To stop a service unit that corresponds to a system service, type the following at a shell prompt as
Replace name with the name of the service
unit you want to stop (for example, Example 10.6. Stopping a Service The service unit for the ~]# systemctl stop bluetooth.service 10.2.5. Restarting a Service To restart a service unit that corresponds to a system service, type the following at a shell prompt as
Replace name with the name of the service unit you want to restart (for example,
Certain system services also allow
you to reload their configuration without interrupting their execution. To do so, type as
Note that system services that do not support this feature ignore this command altogether. For convenience, the Example 10.7. Restarting a Service In order to prevent users from
encountering unnecessary error messages or partially rendered web pages, the Apache HTTP Server allows you to edit and reload its configuration without the need to restart it and interrupt actively processed requests. To do so, type the following at a shell prompt as ~]# systemctl reload httpd.service 10.2.6. Enabling a Service To configure a service unit that corresponds to a
system service to be automatically started at boot time, type the following at a shell prompt as
Replace name with the name of the service unit you want to enable (for example,
This command disables the selected service unit and immediately enables it again. For information on how to determine whether a certain service unit is enabled to start at boot time, see Section 10.2.2, “Displaying Service Status”. For information on how to start a service in the current session, see Section 10.2.3, “Starting a Service”. Example 10.8. Enabling a Service To configure the Apache HTTP Server to start automatically
at boot time, run the following command as ~]# systemctl enable httpd.service Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service. 10.2.7. Disabling a Service To prevent a service unit that corresponds to a system service from being automatically started at boot time, type the following at a shell prompt as
Replace name with the name of the service unit you want to disable (for example,
This command replaces the
For information on how to determine whether a certain service unit is enabled to start at boot time, see Section 10.2.2, “Displaying Service Status”. For information on how to stop a service in the current session, see Section 10.2.4, “Stopping a Service”. Example 10.9. Disabling a Service Example 10.6, “Stopping a Service” illustrates how to stop the ~]# systemctl disable bluetooth.service Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service. Removed symlink /etc/systemd/system/dbus-org.bluez.service. 10.2.8. Starting a Conflicting ServiceIn systemd, positive and negative dependencies between services exist. Starting particular service may require starting one or more other services (positive dependency) or stopping one or more services (negative dependency). When you attempt to start a new service, systemd resolves all dependencies automatically. Note that this is done without explicit notification to the user. If you are already running a service, and you attempt to start another service with a negative dependency, the first service is automatically stopped. For example, if you are running the 10.3. Working with systemd TargetsPrevious versions of Red Hat Enterprise Linux, which were distributed with SysV init or Upstart, implemented a predefined set of runlevels that represented specific modes of operation. These runlevels were numbered from 0 to 6 and were defined by a selection of system services to be run when a particular runlevel was enabled by the system administrator. In Red Hat Enterprise Linux 7, the concept of runlevels has been replaced with systemd targets. Systemd targets are represented by target units. Target units end with the Red Hat Enterprise Linux 7 is distributed with a number of predefined targets that are more or less similar to the standard set of runlevels from the previous releases of this system. For compatibility reasons, it also provides aliases for these targets that directly map them to SysV runlevels. Table 10.6, “Comparison of SysV Runlevels with systemd Targets” provides a complete list of SysV runlevels and their corresponding systemd targets. Table 10.6. Comparison of SysV Runlevels with systemd Targets
To view, change, or configure systemd targets, use the Table 10.7. Comparison of SysV init Commands with systemctl
10.3.1. Viewing the Default TargetTo determine which target unit is used by default, run the following command:
This command resolves the symbolic link located at Example 10.10. Viewing the Default Target To display the default target unit, type: ~]$ 10.3.2. Viewing the Current TargetTo list all currently loaded target units, type the following command at a shell prompt:
For each target unit, this commands displays its full name ( By default, the
See Section 10.3.1, “Viewing the Default Target” for information on how to display the default target. For information on how to change the current target, see Section 10.3.4, “Changing the Current Target”. Example 10.11. Viewing the Current Target To list all currently loaded target units, run the following command: ~]$ 10.3.3. Changing the Default Target To configure the system to use a different target unit
by default, type the following at a shell prompt as
Replace name with the name of the target unit you want to use by default (for example, Example 10.12. Changing the Default Target To configure the
system to use the ~]# systemctl set-default multi-user.target rm '/etc/systemd/system/default.target' ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target' 10.3.4. Changing the Current Target To change to a different target unit in the current session, type the following at a shell prompt as
Replace name with the name of the target unit you want to use (for example,
Example 10.13. Changing the Current Target To turn off the graphical user interface and change to the ~]# systemctl isolate multi-user.target 10.3.5. Changing to Rescue ModeRescue mode provides a convenient single-user environment and allows you to repair your system in situations when it is unable to complete a regular booting process. In rescue mode, the system attempts to mount all local file systems and start some important system services, but it does not activate network interfaces or allow more users to be logged into the system at the same time. In Red Hat Enterprise Linux 7, rescue mode is equivalent to single user mode and requires the root password. To change the current target and enter rescue mode in the current session, type the following at a shell prompt as
This command is similar to
For information on how to enter emergency mode, see Section 10.3.6, “Changing to Emergency Mode”. Example 10.14. Changing to Rescue Mode To enter rescue mode in the
current session, run the following command as ~]# systemctl rescue Broadcast message from root@localhost on pts/0 (Fri 2013-10-25 18:23:15 CEST): The system is going down to rescue mode NOW! 10.3.6. Changing to Emergency ModeEmergency mode provides the most minimal environment possible and allows you to repair your system even in situations when the system is unable to enter rescue mode. In emergency mode, the system mounts the root file system only for reading, does not attempt to mount any other local file systems, does not activate network interfaces, and only starts a few essential services. In Red Hat Enterprise Linux 7, emergency mode requires the root password. To change the current target and enter emergency mode, type the following at a shell prompt as
This command is similar to
For information on how to enter rescue mode, see Section 10.3.5, “Changing to Rescue Mode”. Example 10.15. Changing to Emergency Mode To enter emergency mode without sending a message to all users that are currently logged into the system, run the following command as ~]# systemctl --no-wall emergency 10.4. Shutting Down, Suspending, and Hibernating the System In Red Hat
Enterprise Linux 7, the Table 10.8. Comparison of Power Management Commands with systemctl
10.4.1. Shutting Down the System The Using systemctl Commands To shut down the system and power off the machine, type the following at a shell prompt as
To shut down and halt the system without powering off the machine, run the following command as
By default, running
either of these commands causes systemd to send an informative message to all users that are currently logged into the system. To prevent systemd from sending this message, run the selected command with the
Using the shutdown Command To shut down the system and power off the machine at a certain time, use a command in the following format as
Where hh:mm
is the time in 24 hour clock format. The To shut down and halt the system after a delay, without powering off the machine, use a command in the following format as shutdown --halt +m Where +m is the delay time in minutes. The A pending shutdown can be canceled by the
See the 10.4.2. Restarting the System To restart the system, run the following command as
By default, this command causes systemd to send an informative message to all users that are currently logged into
the system. To prevent systemd from sending this message, run this command with the
10.4.3. Suspending the System To suspend the system, type the following at a shell prompt as
This command saves the system state in RAM and with the exception of the RAM module, powers off most of the devices in the machine. When you turn the machine back on, the system then restores its state from RAM without having to boot again. Because the system state is saved in RAM and not on the hard disk, restoring the system from suspend mode is significantly faster than restoring it from hibernation, but as a consequence, a suspended system state is also vulnerable to power outages. For information on how to hibernate the system, see Section 10.4.4, “Hibernating the System”. 10.4.4. Hibernating the System To hibernate the system, type the
following at a shell prompt as
This command saves the system state on the hard disk drive and powers off the machine. When you turn the machine back on, the system then restores its state from the saved data without having to boot again. Because the system state is saved on the hard disk and not in RAM, the machine does not have to maintain electrical power to the RAM module, but as a consequence, restoring the system from hibernation is significantly slower than restoring it from suspend mode. To hibernate and suspend the system, run the following command as
For information on how to suspend the system, see Section 10.4.3, “Suspending the System”. 10.5. Controlling systemd on a Remote Machine In addition to controlling the systemd system and service manager locally, the systemctl --host user_name@host_name command Replace user_name with the name of the remote user, host_name with the machine’s host name, and Example 10.16. Remote Management To log in to a remote machine named ~]$ 10.6. Creating and Modifying systemd Unit Files A unit file contains configuration directives that describe the unit and define its behavior. Several Unit file names take the following form: unit_name.type_extension Here, unit_name stands for the name of the unit and type_extension identifies the unit type, see
Table 10.1, “Available systemd Unit Types” for a complete list of unit types. For example, there usually is Unit files can be supplemented with a
directory for additional configuration files. For example, to add custom configuration options to Also, the Many unit file options can be set using the so called unit specifiers – wildcard strings that are dynamically replaced with unit parameters when the unit file is loaded. This enables creation of generic unit files that serve as templates for generating instantiated units. See Section 10.6.5, “Working with Instantiated Units” for details. 10.6.1. Understanding the Unit File StructureUnit files typically consist of three sections:
Table 10.9. Important [Unit] Section Options
Table 10.10. Important [Service] Section Options
Table 10.11. Important [Install] Section Options
A whole range of options that can be used to fine tune the unit configuration, Example 10.17, “postfix.service Unit File” shows an example of a service unit installed on the system. Moreover, unit file options can be defined in a way that enables dynamic creation of units as described in Section 10.6.5, “Working with Instantiated Units”. Example 10.17. postfix.service Unit File What follows is the content of the [Unit] Description=Postfix Mail Transport Agent After=syslog.target network.target Conflicts=sendmail.service exim.service [Service] Type=forking PIDFile=/var/spool/postfix/pid/master.pid EnvironmentFile=-/etc/sysconfig/network ExecStartPre=-/usr/libexec/postfix/aliasesdb ExecStartPre=-/usr/libexec/postfix/chroot-update ExecStart=/usr/sbin/postfix start ExecReload=/usr/sbin/postfix reload ExecStop=/usr/sbin/postfix stop [Install] WantedBy=multi-user.target The [Unit] section describes the service, specifies the ordering dependencies, as well as conflicting units. In [Service], a sequence of custom scripts is specified to be executed during unit
activation, on stop, and on reload. 10.6.2. Creating Custom Unit FilesThere are several use cases for creating unit files from scratch: you could run a custom daemon, create a second instance of some existing service (as in Example 10.19, “Creating a second instance of the sshd service”), or import a SysV init script (more in Section 10.6.3, “Converting SysV Init Scripts to Unit Files”). On the other hand, if you intend just to modify or extend the behavior of an existing unit, use the instructions from Section 10.6.4, “Modifying Existing Unit Files”. The following procedure describes the general process of creating a custom service:
Example 10.18. Creating the emacs.service File When using the Emacs text editor, it is often faster and more convenient to have it running in the background instead of starting a new instance of the program whenever editing a file. The following steps show how to create a unit file for Emacs, so that it can be handled like a service.
As the editor is now registered as a systemd service, you can use all standard Example 10.19. Creating a second instance of the sshd service System Administrators often need to configure and run multiple instances of a
service. This is done by creating copies of the original service configuration files and modifying certain parameters to avoid conflicts with the primary instance of the service. The following procedure shows how to create a second instance of the
Additional information with some real-world examples of cases triggered by the ordering and dependencies in a unit file is available in the following article: Is there any useful information about writing unit files? If you want to set limits for services started by 10.6.3. Converting SysV Init Scripts to Unit FilesBefore taking time to convert a SysV init script to a unit file, make sure that the conversion was not already done elsewhere. All core services installed on Red Hat Enterprise Linux 7 come with default unit files, and the same applies for many third-party software packages. Converting an init script to a unit file requires analyzing the script and extracting the necessary information from it. Based on this data you can create a unit file as described in Section 10.6.2, “Creating Custom Unit Files”. As init scripts can vary greatly depending on the type of the service, you might need to employ more configuration options for translation than outlined in this chapter. Note that some levels of customization that were available with init scripts are no longer supported by systemd units, see Section 10.1.2, “Compatibility Changes”. The majority of information needed for conversion is provided in
the script’s header. The following example shows the opening section of the init script used to start the #!/bin/bash # # postfix Postfix Mail Transfer Agent # # chkconfig: 2345 80 30 # description: Postfix is a Mail Transport Agent, which is the program \ # that moves mail from one machine to another. # processname: master # pidfile: /var/spool/postfix/pid/master.pid # config: /etc/postfix/main.cf # config: /etc/postfix/master.cf ### BEGIN INIT INFO # Provides: postfix MTA # Required-Start: $local_fs $network $remote_fs # Required-Stop: $local_fs $network $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop postfix # Description: Postfix is a Mail Transport Agent, which is the program that # moves mail from one machine to another. ### END INIT INFO In the above example, only lines starting with # chkconfig and # description are mandatory, so you might not find the rest in different init files. The text enclosed between the # BEGIN INIT INFO and # END INIT INFO lines is called Linux Standard Base (LSB) header. If specified, LSB headers contain directives defining the service description, dependencies, and default runlevels. What follows is an overview of analytic tasks aiming to collect the data needed for a new unit file. The postfix init script is used as an example, see the resulting postfix unit file in Example 10.17, “postfix.service Unit File”. Finding the Service Description Find descriptive information about the script on the line starting with
#description. Use this description together with the service name in the Finding Service DependenciesThe LSB header might contain several directives that form dependencies between services. Most of them are translatable to systemd unit options, see Table 10.12, “Dependency Options from the LSB Header” Table 10.12. Dependency Options from the LSB Header
Finding Default Targets of the Service The line starting with #chkconfig contains three numerical values. The most important is the first number that represents the default runlevels in which the service is started. Use
Table 10.6, “Comparison of SysV Runlevels with systemd Targets” to map these runlevels to equivalent systemd targets. Then list these targets in the The other two values specified on the #chkconfig line represent startup and shutdown priorities of the init script. These values are interpreted by systemd if it loads the init script, but there is no unit file equivalent. Finding Files Used by the Service Init scripts require loading a function library from a dedicated directory and allow importing configuration, environment, and PID files. Environment variables are
specified on the line starting with #config in the init script header, which translates to the The key information that is not included in the init script header is the path to the service executable, and potentially some other files required by the service. In previous versions of Red Hat Enterprise Linux,
init scripts used a Bash case statement to define the behavior of the service on default actions, such as start, stop, or restart, as well as custom-defined actions. The following excerpt from the conf_check() { [ -x /usr/sbin/postfix ] || exit 5 [ -d /etc/postfix ] || exit 6 [ -d /var/spool/postfix ] || exit 5 } make_aliasesdb() { if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ] then # /etc/aliases.db might be used by other MTA, make sure nothing # has touched it since our last newaliases call [ /etc/aliases -nt /etc/aliases.db ] || [ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] || [ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return /usr/bin/newaliases touch -r /etc/aliases.db "$ALIASESDB_STAMP" else /usr/bin/newaliases fi } start() { [ "$EUID" != "0" ] && exit 4 # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 1 conf_check # Start daemons. echo -n $"Starting postfix: " make_aliasesdb >/dev/null 2>&1 [ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE /usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start" RETVAL=$? [ $RETVAL -eq 0 ] && touch $lockfile echo return $RETVAL } The extensibility of the init script allowed specifying two custom functions, Systemd supports only the predefined actions, but enables executing custom executables with Converting complex init scripts requires understanding the purpose of every statement in the script. Some of the statements are specific to the operating system version, therefore you do not need to translate them. On the other hand, some adjustments might be needed in the new environment, both in unit file as well as in the service executable and supporting files. 10.6.4. Modifying Existing Unit Files Services installed on the system come with default unit files that are stored in the
In order to return to the default configuration of the unit, just delete custom-created configuration files in
The
Also, if the modified unit file belongs to a running service, this service must be restarted to accept new settings:
To modify properties, such as
dependencies or timeouts, of a service that is handled by a SysV initscript, do not modify the initscript itself. Instead, create a For example, to extend the
configuration of the Extending the Default Unit Configuration To extend the default unit file with additional
configuration options, first create a configuration directory in
Replace name with the name of the service you want to extend. The above syntax applies to all unit types. Create a configuration file in the directory made in the previous step. Note that the file name must end with the .conf suffix. Type: touch /etc/systemd/system/name.service.d/config_name.conf Replace config_name with the name of the configuration file. This file adheres to the normal unit file structure, therefore all directives must be specified under appropriate sections, see Section 10.6.1, “Understanding the Unit File Structure”. For example, to add a custom dependency, create a configuration file with the following content: [Unit] Requires=new_dependency After=new_dependency Where new_dependency stands for the unit to be marked as a dependency. Another example is a configuration file that restarts the service after its main process exited, with a delay of 30 seconds: [Service] Restart=always RestartSec=30 It is recommended to create small configuration files focused only on one task. Such files can be easily moved or linked to configuration directories of other services. To apply changes made to the unit, execute as
Example 10.20. Extending the httpd.service Configuration To modify the httpd.service unit so that a custom shell script is automatically executed when starting the Apache service, perform the following steps. First, create a directory and a custom configuration file: ~]# mkdir /etc/systemd/system/httpd.service.d/ ~]# touch /etc/systemd/system/httpd.service.d/custom_script.conf Provided that the script you want to start automatically with Apache is located at [Service] ExecStartPost=/usr/local/bin/custom.sh To apply the unit changes, execute: ~]# systemctl daemon-reload ~]# systemctl restart httpd.service The configuration files from configuration directories in Overriding the Default Unit Configuration To make changes that will persist after updating the package that provides the unit file, first copy the file to the
Where name stands for the name of the service unit you wish to modify. The above syntax applies to all unit types.
Open the copied file with a text editor, and make the desired changes. To apply the unit changes, execute as
Example 10.21. Changing the timeout limit You can specify a timeout value per service to prevent a malfunctioning service from freezing the system. Otherwise, timeout is set by default to 90 seconds for normal services and to 300 seconds for SysV-compatible services.
For example, to extend timeout limit for the
Monitoring Overriden UnitsTo display an overview of overridden or modified unit files, use the following command:
For example, the output of the above command can look as follows: [EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target [OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service --- /usr/lib/systemd/system/autofs.service 2014-10-16 21:30:39.000000000 -0400 +++ /etc/systemd/system/autofs.service 2014-11-21 10:00:58.513568275 -0500 @@ -8,7 +8,8 @@ EnvironmentFile=-/etc/sysconfig/autofs ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid ExecReload=/usr/bin/kill -HUP $MAINPID -TimeoutSec=180 +TimeoutSec=240 +Restart=Always [Install] WantedBy=multi-user.target [MASKED] /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service [EXTENDED] /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf 4 overridden configuration files found. Table 10.13, “systemd-delta Difference Types” lists override types that can appear in the output of Table 10.13. systemd-delta Difference Types
It is good practice to run
10.6.5. Working with Instantiated Units
It is possible to instantiate multiple units from a single template configuration file at runtime. The "@" character is used to mark the template and to associate units with it. Instantiated units can be started from another unit file (using template_name@instance_name.service Where template_name stands for the name of the template configuration file. Replace instance_name with the name for the unit instance. Several instances can point to the same template file with configuration options common for all instances of the unit. Template unit name has the form of: unit_name@.service For example, the following Wants=, first makes systemd search for given service units. If no such units are found, the part between "@" and the type suffix is ignored and systemd searches for the Wildcard characters, called unit specifiers, can be used in any unit configuration file. Unit specifiers substitute certain unit parameters and are interpreted at runtime. Table 10.14, “Important Unit Specifiers” lists unit specifiers that are particularly useful for template units. Table 10.14. Important Unit Specifiers
For a complete list of unit specifiers, see the For example, the [Unit] Description=Getty on %I ... [Service] ExecStart=-/sbin/agetty --noclear %I $TERM ... When the and are instantiated form the above template,
10.7. Additional Considerations While Managing ServicesDuring normal operation, systemd maintains an association between a unit abstraction and the underlying processes active on the system. From: Processes systemd spawns are placed in individual Linux control groups named after the unit which they belong to in the private systemd hierarchy. (see cgroups.txt[1] for more information about control groups, or short "cgroups"). systemd uses this to effectively keep track of processes. Control group information is maintained in the kernel, and is accessible via the file system hierarchy (beneath /sys/fs/cgroup/systemd/), or in tools such as ps(1) (ps xawf -eo pid,user,cgroup,args is particularly useful to list all processes and the systemd units they belong to). The cgroup hierarchy is critical to systemd’s view of process and service health. When a process forks itself, it inherits the cgroup of the creating process. With this being the case, all processes associated with a given unit can be verified by reading the contents of the applicable cgroup.procs file, such as: ~]# cat /sys/fs/cgroup/systemd/system.slice/httpd.service/cgroup.procs 11854 11855 11856 11857 11858 11859 The output matches the CGroup information returned during a ~]# systemctl status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2019-05-29 12:08:16 EDT; 45s ago Docs: man:httpd(8) man:apachectl(8) Main PID: 11854 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─11854 /usr/sbin/httpd -DFOREGROUND ├─11855 /usr/sbin/httpd -DFOREGROUND ├─11856 /usr/sbin/httpd -DFOREGROUND ├─11857 /usr/sbin/httpd -DFOREGROUND ├─11858 /usr/sbin/httpd -DFOREGROUND └─11859 /usr/sbin/httpd -DFOREGROUND May 29 12:08:16 localhost systemd[1]: Starting The Apache HTTP Server... May 29 12:08:16 localhost systemd[1]: Started The Apache HTTP Server. To directly view these groupings of processes system-wide, the ~]# systemd-cgls | head -17 ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22 ├─user.slice │ └─user-0.slice │ └─session-168.scope │ ├─ 3049 login -- root │ ├─11884 -bash │ ├─11943 systemd-cgls │ └─11944 head -17 └─system.slice ├─httpd.service │ ├─11854 /usr/sbin/httpd -DFOREGROUND │ ├─11855 /usr/sbin/httpd -DFOREGROUND │ ├─11856 /usr/sbin/httpd -DFOREGROUND │ ├─11857 /usr/sbin/httpd -DFOREGROUND │ ├─11858 /usr/sbin/httpd -DFOREGROUND │ └─11859 /usr/sbin/httpd -DFOREGROUND ├─rhnsd.service In order for systemd to function properly, the service must be started or stopped through the systemd system to maintain the correct process to unit grouping. Any operation that takes external action results in the necessary cgroup structure not being created. This happens because systemd is not aware of the special nature of the processes being started. As an example of the above constraint, stopping the ~]# systemctl stop httpd ~]# /usr/sbin/httpd # systemd-cgls | head -17 ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22 ├─user.slice │ └─user-0.slice │ └─session-168.scope │ ├─ 3049 login -- root │ ├─11884 -bash │ ├─11957 /usr/sbin/httpd │ ├─11958 /usr/sbin/httpd │ ├─11959 /usr/sbin/httpd │ ├─11960 /usr/sbin/httpd │ ├─11961 /usr/sbin/httpd │ ├─11962 /usr/sbin/httpd │ ├─11963 systemd-cgls │ └─11964 head -17 └─system.slice ├─rhnsd.service │ └─3261 rhnsd Note that the
Non-graceful application shutdown events can result in a large number of subsequent application failures, such as client-side failures, data loss, and on-disk corruption. 10.8. Additional ResourcesFor more information on systemd and its usage on Red Hat Enterprise Linux 7, see the resources listed below. Installed Documentation
Online Documentation
See Also
What is contained in the display variable on a Linux system?What is contained in the DISPLAY variable on a Linux system running the X window system? The resolution of the monitor connected to the Linux system.
Which of the following files is where the default run level is set on some Linux systems?The default runlevel is specified in /etc/inittab file in most Linux operating systems.
Where are scheduled commands stored on Ubuntu Linux systems?Each user profile on the system can have their own crontab where they can schedule jobs, which is stored under /var/spool/cron/crontabs/ . To schedule a job, open up your crontab for editing and add a task written in the form of a cron expression.
In which directory would a system administrator store scripts?/root. The root user's home directory is an important one to include in a backup. This directory is where you, the system administrator, keep downloads, configurations, scripts, notes, and other essential information that is often unique and irreplaceable.
|