Linux Systemd detailed

CentOS 7 replaces SysV with SYSTEMD. The purpose of the SYSTEMD is to replace the INIT system that has been in use since the Unix era, to be compatible with SYSV and LSB startup scripts, and to boot the load service more efficiently during the process startup process.

The SYSTEMD features are:

• Support for parallelization tasks
• At the same time, socket-type and d-bus-bus activation service are adopted.
• Start daemon on demand (daemon);
• Utilize Linux's cgroups monitoring process;
• Support snapshot and system recovery;
• Maintain mount points and automatic mount points;
• Precision control based on dependencies between services.

SYSTEMD Basic Tools

The main command to view and control Systemd is systemctl. This command can be used to view system status and manage systems and services. See Man 1 Systemctl.

Tips:

• Add the-H < username >@< hostname > to the SYSTEMCTL parameter to allow remote control of other machines. The procedure uses SSH links.
• Systemadm is the official graphic front end of Systemd

Analyze System Status

Output the active unit:

1. $ systemctl

The following commands are equivalent:

1. $ systemctl List-units

Outputs the unit that failed to run:

1. $ systemctl--failed

All available cell files are stored in the/usr/lib/systemd/system/and/etc/systemd/system/directories (the latter with higher precedence). To view all installed services:

1. $ systemctl List-unit-files

Working with units

A unit configuration file can describe one of the following: System service (. Service), Mount Point (. Mount), sockets (. Sockets), System device (. device), swap partition (. swap), file path (. path), Start the target (. Target), a timer (. timer) that is managed by SYSTEMD. See man 5 systemd.unit for details.

When using the Systemctl control unit, you typically need to use the full name of the cell file, including the extension (for example, Sshd.service). However, some units can use shorthand in Systemctl.

• If there is no extension, systemctl defaults to the extension as. Service. For example Netcfg and Netcfg.service are equivalent.
• The mount point is automatically converted to the corresponding. Mount unit. For example,/home is equivalent to Home.mount.
• The device is automatically converted to the corresponding. Device unit, so/dev/sda2 is equivalent to Dev-sda2.device.

Note: Some cell names contain an @ tag, (e.g. [email protected]): This means that it is an instance of the template unit [email protected]. String is called the instance identifier, and when Systemctl invokes a template unit, it is passed as a parameter to the template unit, which uses the passed-in parameter instead of the%I in the template. Indicator. Before instantiating, SYSTEMD will first check whether the [email protected] file exists (if it exists, it should be used directly instead of the template instantiation). In most cases, shifting the @ mark means that the file is a template. If a template unit is called without instantiation, the call returns a failure because the%I in the template unit The indicator is not replaced.

Activate the unit now:

1. # Systemctl Start < units >

To stop the unit immediately:

1. # Systemctl Stop < unit >

Restart Unit:

1. # Systemctl Restart < units >

The command unit re-reads the configuration:

1. # Systemctl Reload < units >

Output Unit Run Status:

1. $ systemctl Status < units >

Check whether the unit is configured to start automatically:

1. $ systemctl is-enabled < units >

Automatic activation Unit:

1. # Systemctl Enable < units >

Note: If the service does not have an install paragraph, it generally means that they should be called automatically through other services. If you really need to install manually, you can connect directly to the service as follows (replace Foo with the real service name):

1. # ln-s/usr/lib/systemd/system/foo.service/etc/systemd/system/graphical.target.wants/

To cancel the power-on auto-activation unit:

1. # systemctl Disable < units >

The manual page of the display unit (must be provided by the unit file):

1. # Systemctl Help < units >

Reload the SYSTEMD to scan for new or changed units:

1. # Systemctl Daemon-reload

Power Management

Power management can only be used after installing Polkit.

If you are logged in to a local Systemd-logind user session and there are currently no other active sessions, the following commands do not require root access. Otherwise (for example, if another user is currently logged on to a TTY), SYSTEMD will automatically request a root password.

Restart:

1. $ systemctl Reboot

Exit the system and stop the power supply:

1. $ systemctl Poweroff

Standby:

1. $ systemctl Suspend

Dormancy:

1. $ systemctl Hibernate

Mixed sleep mode (simultaneously hibernate to hard disk and standby):

1. $ systemctl Hybrid-sleep

Writing Unit files

The syntax for the Systemd cell file is derived from the XDG desktop Portal configuration file, the original source of the. ini file for Microsoft Windows. The unit files can be loaded from two places, with priority levels from low to high, respectively:

• /usr/lib/systemd/system/: Package Installation Unit
• /etc/systemd/system/: Unit installed by system administrator

Note: When SYSTEMD is running in user mode, the load path used is completely different.

The syntax of the unit file can refer to the unit already installed in the system, or refer to the examples section in Man Systemd.service.

Tip: Comments that begin with # may also be used in unit-files, but only in new lines. Do not use the end-of-line comment after the systemd parameter, or the unit will fail to start.

Handling dependencies

When using SYSTEMD, you can resolve their dependencies by writing the unit configuration file correctly. Typically, unit a requires unit B to run before a starts. In this case, add requires=b and after=b to the [unit] segment in the cell a configuration file. If this dependency is optional, you can add wants=b and after=b. Note that wants= and requires= do not imply after=, that is, if the after= option is not established, the two units will be started in parallel.

Dependencies are typically used on services (service) rather than targets. For example, Network.target is typically introduced by a service that configures a network interface, so the custom cell is queued after the service because Network.target is already started.

Service type

When you write a custom service file, you can choose several different ways to start your services. The startup mode can be set through the type= parameter in the configuration file [Service] segment.

• Type=simple (default): Systemd thinks the service will start immediately. The service process does not fork. If the service is to start another service, do not use this type to start unless the service is socket-activated.
• Type=forking:systemd believes that when the service process is fork and the parent process exits, the service starts successfully. For a regular daemon (daemon), use this type to start up unless you are sure that this startup mode does not meet your requirements. Use this startup type to specify pidfile= at the same time so that SYSTEMD can track the main process of tracking.
• Type=oneshot: This option applies to services that perform only one task and then exit immediately. You may need to set remainafterexit=yes at the same time so that Systemd still thinks the service is active after the service process exits.
• Type=notify: Same as Type=simple, but the contract service sends a signal to SYSTEMD when it is ready. The implementation of this notification is provided by libsystemd-daemon.so.
• Type=dbus: If started in this manner, when the specified busname appears on the Dbus system bus, SYSTEMD considers the service ready.
• Type=idle:systemd waits for all tasks to complete before starting to execute an idle type of cell. In addition, other behaviors are similar to type=simple.

For more explanations of type, refer to Systemd.service (5).

Modify an existing cell file

To change the unit file provided by the package, first create a directory named/etc/systemd/system/< cell name >.d/(such as/etc/systemd/system/httpd.service.d/), and then put the *.conf file, Where you can add or reset parameters. The parameter set here takes precedence over the original unit file. For example, if you want to add an additional dependency, create such a file:

1. /etc/systemd/system/<unit>.d/customdependency.conf
2. [Unit]
3. Requires=< new dependencies >
4. After=< new dependencies >

Other examples,

1. /etc/systemd/system/unit.d/customexec.conf
3. [Service]
4. Execstartexecstart=
5. Execstart=new command

Want to know why you must empty the execstart before modifying it

Here is an example of an automatic restart service:

1. /etc/systemd/system/unit.d/restart.conf
3. [Service]
4. restart= always
5. restartsec=

Then run the following command to make the changes effective:

1. # Systemctl Daemon-reload
2. # Systemctl Restart < units >

In addition, the same effect can be achieved by copying the old unit files from/usr/lib/systemd/system/to/etc/systemd/system/and then modifying them. The cell files in the/etc/systemd/system/directory are always prioritized higher than the cell files of the same name in the/usr/lib/systemd/system/directory. Note that when the unit files in/usr/lib/are changed due to package upgrades, the custom cell files in/etc/do not synchronize updates. In addition, you have to perform Systemctl reenable <unit>, and manually re-enable the unit. Therefore, it is recommended to use the previous method of using *.conf.

Tip: Use the Systemd-delta command to see which cell files are overwritten and which are modified. system maintenance needs to know in time which units have been updated

Vim syntax highlighting for unit profiles support

The VIM-SYSTEMD software package can be installed from the official warehouse, allowing the unit configuration file to support syntax highlighting under VIM.

Goal (target)

The start level (RunLevel) is an old concept. Now, SYSTEMD introduces a concept that is similar and different from the start-up level-target. Unlike the start level represented by numbers, each target has a name and unique functionality, and can be enabled multiple at the same time. Some goals inherit services from other targets and start new services. SYSTEMD provides some targets that mimic the sysvinit boot level and can still be toggled using the old telinit boot level command.
Get current target

Do not use the RunLevel command:

1. $ systemctl list-units --type=target

Create a new target

In Fedora, boot levels 0, 1, 3, 5, 6 are assigned to a specific purpose, and all correspond to a systemd target. However, there is no good way to migrate user-defined boot levels (2, 4). To achieve similar functionality, you can create a new target/etc/systemd/system/< (/usr/lib/systemd/system/graphical.target) based on the original boot level and create /etc/systemd/system/< the new target >.wants directory, with links to additional services (pointing to the cell files in/usr/lib/systemd/system/).

Target table

SysV Boot Level	Systemd Target	Notes
0	Runlevel0.target, Poweroff.target	Interrupt System (Halt)
1, S, single	Runlevel1.target, Rescue.target	Single-User mode
2, 4	Runlevel2.target, Runlevel4.target, Multi-user.target	User-defined boot level, usually identified as Level 3.
3	Runlevel3.target, Multi-user.target	Multi-user, no graphical interface. Users can log on through a terminal or network.
5	Runlevel5.target, Graphical.target	Multi-user, graphical interface. Inherit level 3 services and start the graphical interface service.
6	Runlevel6.target, Reboot.target	Restart
Emergency	Emergency.target	First Aid mode (Emergency shell)

Toggle Start Level/target

SYSTEMD, the start level is accessed through the target unit. Switch by using the following command:

1. # Systemctl Isolate Graphical.target

This command has no effect on the next boot. Equivalent to Telinit 3 or Telinit 5.

Modify default boot Level/target

The target for boot-in is Default.target, which is the default link to Graphical.target (roughly equivalent to the original boot level 5). The default boot level can be changed through kernel parameters:

Tip: You can omit the extension. Target.

• Systemd.unit=multi-user.target (roughly equivalent to level 3)
• Systemd.unit=rescue.target (roughly equivalent to level 1)

Another way is to modify the Default.target. You can modify it by Systemctl:

1. # Systemctl Enable Multi-user.target

The command execution is shown by Systemctl: The link/etc/systemd/system/default.target is created, pointing to the new default boot level. This method is valid when and only if the following contents are in the target configuration file:

1. [Install]
2. alias=Default.target

At present, Multi-user.target and graphical.target all contain this content.

Temporary files

The files in/usr/lib/tmpfiles.d/and/etc/tmpfiles.d/describe how Systemd-tmpfiles creates, cleans, and deletes temporary files and directories, which are usually stored in/run and/tmp. The profile name is called/etc/tmpfiles.d/<program>.conf. The configuration here can overwrite the configuration with the same name in the/usr/lib/tmpfiles.d/directory.

Temporary files are usually provided at the same time as the service file to generate the files and directories required by the daemon. For example, the Samba service requires directory/run/samba to exist and set the correct permission bit, as in this case:

1. /usr/lib/tmpfiles.d/samba.conf
2. D/run/samba 0755 Root root

In addition, temporary files can be used to write certain content to specific files at boot time. For example, to prevent the system from waking up from a USB device, use the old/etc/rc.local to use the echo usbe >/proc/acpi/wakeup, and now you can:

1. /etc/tmpfiles.d/disable-usb-wake.conf
2. W/proc/acpi/wakeup----USBE

See man 5 tmpfiles.d for details.

Note: This method cannot add parameters to the configuration file in/sys because it is possible for Systemd-tmpfiles-setup to run before the relevant module is loaded. In this case, you need to first verify the required parameters through the Modinfo < module name > and set the parameters in a file under/ETC/MODPROBE.D. In addition, you can use Udev rules to set the appropriate properties when the device is ready.

Timer

The timer is a configuration file with a. timer suffix, which records the action triggered by the time inside the system, and the timer can replace most of the features of Cron.

Log

SYSTEMD provides its own log system (logging systems), called Journal. With SYSTEMD logs, no additional installation log service (syslog) is required. command to read the log:

1. # Journalctl

By default (when Storage= is set to auto in file/etc/systemd/journald.conf), log records are written to/var/log/journal/. This directory is part of the SYSTEMD software package. If it is deleted, SYSTEMD does not automatically create it until the next time the package is upgraded. If the directory is missing, Systemd writes log records to/run/systemd/journal. This means that the log will be lost after the system restarts.

Tip: If/var/log/journal/is located in the Btrfs file system, you should consider disabling write-time replication for this directory

Filter output

Journalctl can filter output based on specific fields, for example:

Show all logs after this startup:

1. # Journalctl-b

However, the general concern is not the log after this startup, but the last time it started (for example, the system crashed just now). You can use the-B parameter:

• Journalctl-b-0 shows the information of this launch
• Journalctl-b-1 shows the information that was last started
• Journalctl-b-2 shows information on last boot Journalctl-b 2
• Show all messages from date (and optional time):

1. # journalctl --since="2012-10-30 18:17:16"

• Show all messages since minutes ago:

1. # journalctl--since "min ago"

• Show the latest information

1. # journalctl-f

• Show all messages for a specific program:

1. # JOURNALCTL/USR/LIB/SYSTEMD/SYSTEMD

• Show all messages for a particular process:

1. # journalctl _pid=1

• Displays all messages for the specified cell:

1. # journalctl-u Netcfg

• Show Kernel ring buffer:

1. # journalctl-k

• Show Auth.log equivalent by filtering on Syslog facility:

1. # journalctl-f- l syslog_facility=

See the man journalctl, the man Systemd.journal-fields, and Lennert's blog post for details.

Log size limit

If you keep the log as above, the default log is limited to 10% of the file system capacity, that is, if/var/log/journal is stored in the root partition of 50GiB, the log will store up to 5GiB of data. You can modify the Systemmaxuse in/etc/systemd/journald.conf to specify the maximum limit. If limit log maximum 50MiB:

1. systemmaxuse=50M

See Man journald.conf for details.

Use with Syslog

SYSTEMD provides socket/run/systemd/journal/syslog to be compatible with traditional log services. All system information will be passed in. To make the legacy Log service work, you need to have the service link to the socket, not/dev/log (official note). The syslog-ng in the Arch software repository already contains the required configuration.

Set Boot syslog-ng:

1. # Systemctl Enable Syslog-ng

Here is a very good guide to Journalctl.

Forward Journald To/dev/tty12

In/etc/systemd/journald.conf enable the following:

1. forwardtoconsole=Yes
2. Ttypath=/dev/tty12
3. maxlevelconsole=Info

Restart Journald:

1. # systemctl Restart Systemd-journald

Troubleshooting Shutdown/Restart very slowly

If the shutdown is particularly slow (even as it freezes), it is likely that a service that refuses to quit is at stake. SYSTEMD will wait for a while before trying to kill it. Please read this article to confirm whether you are the victim of the problem.

Short-time process with no log records

If Journalctl-u Foounit.service does not show any output for a short-term process, use a PID test instead. For example, if the Systemd-modules-load.service execution fails, first query its PID (for example, 123) with the Systemctl status Systemd-modules-load, and then retrieve the PID-related log Journalctl-b _pid=123. Log metadata for the run-time process (such as _systemd_unit and _comm) is collected in the/proc directory in a disorderly order. To fix the problem, you must modify the kernel so that it provides the above data through a socket connection, which is similar to scm_credentials.

Diagnosing startup problems

Boot with the following kernel parameters: Systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1m

Prevent dump memory when a program crashes

To use the old kernel dump, create the following file:

1. /etc/sysctl.d/49-coredump.conf
3. Kernel.core_pattern = Core
4. Kernel.core_uses_pid = 0

Then run:

1. #/usr/lib/systemd/systemd-sysctl

You may also need to perform the "unlimit" Setting File Size:

1. $ ulimit-c Unlimited

Linux Systemd detailed