Shulou(Shulou.com)06/01 Report--

This article mainly explains "the running level of systemd command in linux and its common application". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Now let the editor to take you to learn "the running level of systemd commands in linux and its common applications"!

Run-level vs. Status

SysVInit uses static runlevels to build different startup states, and the following five runlevels are available in most releases:

Single user mode (Single-user mode)

Multi-user mode, do not start network services (Multi-user mode without network services started)

Multi-user mode, starting network services (Multi-user mode with network services started)

System shutdown (System shutdown)

System restart (System reboot)

For me, using multiple runlevels is not very beneficial, but they are always there in the system. Unlike the run level, systemd can create different states, which provide a flexible mechanism to set configuration items at startup. These states consist of multiple unit files, also known as boot targets (target). The startup target has a clear descriptive name, rather than using numbers like the run level. Unit files can control services, devices, sockets, and mount points. Refer to / usr/lib/systemd/system/graphical.target, which is the default startup target for CentOS 7:

The code is as follows:

[Unit]

Description=Graphical Interface

Documentation=man:systemd.special (7)

Requires=multi-user.target

After=multi-user.target

Conflicts=rescue.target

Wants=display-manager.service

AllowIsolate=yes

[Install]

Alias=default.target

Now what does the unit file look like? Let me give you an example. Unit files are stored in the following two directories:

The code is as follows:

/ etc/systemd/system/

/ usr/lib/systemd/system/

We can modify the files in the first directory to customize the configuration, while the files in the second directory are the backup saved during the package installation. / etc/systemd/system/ takes precedence over / usr/lib/systemd/system/. Yes, users take precedence over machines. Here is the unit file for Apache Web server:

The code is as follows:

[Unit]

Description=The Apache HTTP Server

After=network.target remote-fs.target nss-lookup.target

[Service]

Type=notify

EnvironmentFile=/etc/sysconfig/httpd

ExecStart=/usr/sbin/httpd/ $OPTIONS-DFOREGROUND

ExecReload=/usr/sbin/httpd $OPTIONS-k graceful

ExecStop=/bin/kill-WINCH ${MAINPID}

KillSignal=SIGCONT

PrivateTmp=true

[Install]

WantedBy=multi.user.target

Even for beginners, the above documents are very easy to understand. This is much simpler than SysVInit's init file. For comparison, here is a snippet of / etc/init.d/apache2:

The code is as follows:

SCRIPTNAME= "${0,000,000,000 /}"

SCRIPTNAME= "${SCRIPTNAME## [KS] [0-9] [0-9]}"

If [- n "$APACHE_CONFDIR"]; then

If ["${APACHE_CONFDIR##/etc/apache2-}"! = "${APACHE_CONFDIR}"]; then

DIR_SUFFIX= "${APACHE_CONFDIR##/etc/apache2-}"

Else

DIR_SUFFIX=

There are 410 lines in the whole file.

You can check the dependencies of unit files, and I am often intimidated by these complex dependencies:

The code is as follows:

$systemctl list-dependencies httpd.service

Cgroups

Cgroups, or control group, has been around in the Linux kernel for several years, but it wasn't really used until the advent of systemd. Cgroups is described in The kernel documentation as follows: "Control groups provide a hierarchical mechanism to manage task groups, which can be used to aggregate and split task groups, and to manage subsequent subtasks of task groups." In other words, it provides a variety of effective ways to control, limit, and allocate resources. Systemd uses cgroups, and you can easily view it. Use the following command to show the entire cgroup tree on your system:

The code is as follows:

$systemd-cgls

You can use the ps command to view the cgroup tree:

The code is as follows:

$ps xawf-eo pid,user,cgroup,args

Common command set

The following command line shows how to reload the configuration file for the daemon, not the systemd service file. Use this command to activate new configuration items and interrupt business processes as little as possible. Take Apache as an example:

The code is as follows:

# systemctl reload httpd.service

Reloading the service file (service file) requires a complete stop and restart of the service. If the service is dead, you can restore it with the following command line:

The code is as follows:

# systemctl restart httpd.service

You can also restart all daemons with one command. This command reloads the unit files for all daemons, and then regenerates the dependency tree:

The code is as follows:

# systemctl daemon-reload

In unprivileged mode, you can also restart, suspend, and shut down:

The code is as follows:

$systemctl reboot

$systemctl suspend

$systemctl poweroff

At this point, I believe you have a deeper understanding of "the running level of the systemd command in linux and its common applications". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.