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

In the previous article, the author briefly introduces the basic concepts and main features of systemd. Since the vast majority of systemd-related tasks are managed through systemctl commands, this article will focus on the use of systemctl commands. Note that this article is introduced in ubuntu 16.04, and all the demo in this article is done in ubuntu 16.04.

The systemctl command has two main functions:

Control the services running on the systemd system management system

Before introducing these features, let's warm up and learn some information about the systemctl command itself.

Preheating

Check the version of systemd

$systemctl-version

View directories related to systemd and systemctl programs

$whereis systemd$ whereis systemctl

Confirm process 1

As an init system, there should be no doubt that the systemd process is the No.1 process in the system. Let's search for processes related to systemd:

As a result, people couldn't believe their eyes. We found several systemd-related processes, but there was no No.1 process. Let's see who process 1 is:

What is / sbin/init?

Well, / sbin/init is just a link to / lib/systemd/systemd. Process 1 of the system is indeed systemd, but it is called / sbin/init in the ubuntu system.

Manage a single unit

Systemctl provides a set of subcommands to manage a single unit in the following format:

Systemctl [command] [unit]

Command mainly includes:

Start: start the following unit immediately.

Stop: close the following unit immediately.

Restart: immediately shut down and start the following unit, that is, execute stop and then start.

Reload: without closing unit, reload the configuration file for the settings to take effect.

Enable: set the next time you boot, the unit that follows will be started.

Disable: set the next boot time, the following unit will not be started.

Status: the status of the following unit will list whether it is being executed, whether it is started or not, and so on.

Is-active: are there any currently running.

Is-enable: is this unit enabled by default when booting?

Kill: don't be intimidated by the name kill, it actually sends a signal to the process running unit.

Show: lists the configuration of unit.

Mask: log out of unit. After logging out, you will not be able to start the unit.

Unmask: cancel the logout of unit.

Let's first look at the basic information of the service type unit through prometheus.service:

The first line of the output is a basic description of unit.

The Loaded in the second line describes whether the service will be started when the operating system starts. Enabled means to start at boot, and disabled means not to start at boot. The configuration file path to start the service is: / lib/systemd/system/prometheus.service.

The Active in the third line describes the current state of the service, and active (running) indicates that the service is running. If it is inactive (dead), the service is not currently running. Then comes the start-up time of the service.

The Docs on the fourth line provides the address of the online document.

The following Main PID represents the ID of the process, followed by the number of tasks, memory consumed, and CPU resources.

The following Cgroup describes the information related to cgrpup, which the author will introduce in detail in the following articles.

Finally, there is the output log information.

With regard to the startup status of unit, in addition to enable and disable:

Static: this unit cannot be started by itself, but it may be awakened by other enabled services.

Mask: this unit can't be started anyway! Because it has been forcibly cancelled. It can be changed back to its original state through systemctl unmask.

With regard to the running status of unit, Active, in addition to active and inactive, there are:

Active (exited): a service that ends normally after only one execution, and currently there are no programs executing in the system. For example, the quotaon function, which is performed only once when booting or mounting, is this mode! Quotaon does not need to be executed all the time, it is only executed once, and then left to the file system to handle it. Most of the small services usually written in bash shell belong to this type.

Active (waiting): execution is in progress, but wait for other events to continue processing. For example, this is the state of printing-related services.

Enable and disable operation

For example, we create a configuration file / lib/systemd/system/prometheus.service for the prometheus service, and then execute the enable command:

$sudo systemctl enable prometheus.service

The so-called enable is to create a link file under multi-user.target.wants:

Why it is linked to the multi-user.target.wants directory is determined by the configuration information in the prometheus.server file.

View the configuration of unit

Use the show subcommand to view the detailed configuration of unit:

$sudo systemctl show prometheus.service

There is a lot of output here, mainly because a lot of default settings are also displayed.

Logout and anti-logout of unit

If we want to temporarily disable a unit, such as prometheus.service, we can log out of the unit, and the service cannot be started after logging out:

$sudo systemctl mask prometheus.service

From the output in the figure above, we can see that the so-called logout is to link the prometheus.service file to the empty device / dev/null. So the service can no longer be started. Let's try to perform an anti-logout:

$sudo systemctl unmask prometheus.service

The unmask action is to delete the link created in the mask operation.

View unit on the system

Systemctl provides a subcommand to view the unit on the system in the following format:

Systemctl [command] [--type=TYPE] [--all]

Command has:

List-units: lists the currently started unit, and if you add the-all option, it will also list the unit that is not started.

List-unit-files: lists all unit based on the files in the / lib/systemd/system/ directory.

-- type=TYPE: you can filter certain types of unit.

Executing the systemctl command without any arguments lists all started unit:

The system starts a lot of services by default, and the above image only intercepts the first few lines. Here is an introduction to the output:

UNIT: the name of the project, including the categories of each unit (see the extension).

LOAD: whether the configuration of unit is loaded when booting.

ACTIVE: the current state must be matched with the subsequent SUB! This is the content of active when we look at it with systemctl status.

DESCRIPTION: description information.

Note that systemctl takes no parameters, which is actually equivalent to systemctl list-units!

Let's take a look at how many unit are installed on the system:

$sudo systemctl list-unit-files

There are also a lot of results, and we still intercept only part of the results. The STATE here is the startup status of the service we described earlier, including enable and disable, static and mask.

View only certain types of unit

For example, we only want to see the unit of the service type:

$systemctl list-units-type=service-all

Only unit ending in .service will appear this time.

If you want to see the unit assignment of mount type-- type=mount is fine:

View unit that failed to load

If you find that a unit is not working, you can check to see if any of the unit loads failed:

$systemctl-failed

Manage different operating environments (target unit)

By specifying-- type=target, you can use the systemctl list-units command to see how many target are available by default on the system:

There are 27 target in the author's ubuntu 16.04! We will only introduce a few commonly used target here.

Graphical.target: the text interface plus the graphical interface, this target already contains the following multi-user.target.

Multi-user.target: plain text mode!

Rescue.target: when you can't log in using root, systemd will add an extra temporary system when you boot, regardless of your original system. At this point, you can get permission from root to maintain your system.

Emergency.target: emergency handling system errors, you can try to use this mode when you can't use rescue.target!

Shutdown.target: is to perform a shutdown.

Getty.target: you can set the configuration of tty.

The normal mode is multi-user.target and graphical.target, and the rescue mode is mainly rescue.target and more serious emergency.target. If you want to modify the number of tty that can provide login, modify the getty.target.

The following is the format for manipulating the target unit command:

Systemctl [command] [unit.target]

Command has:

Get-default: get the current target.

Set-default: set the following target to become the default mode of operation.

Isolate: switch to the mode that follows.

View and set the default target

$sudo systemctl get-default

The default target of the author's system is graphical.target, so the graphical interface starts by default when starting. Let's set it to multi-user.target:

$sudo systemctl set-default multi-user.target

The actual execution process is to delete the previous linked file and then create a new linked file to / lib/systemd/system/multi-user.target. In this way, the next boot will enter plain text mode by default.

Toggle target

We can also switch between different target without restarting, such as switching from graphical interface to plain text mode:

$sudo systemctl isolate multi-user.target

In general, the switching of different target can be completed by using the above isolate method. However, for convenience, systemd also provides

A few simple instructions are used to switch modes of operation, roughly as follows:

$sudo systemctl poweroff # system shutdown $sudo systemctl reboot # restart $sudo systemctl suspend # enter pause mode $sudo systemctl hibernate # enter hibernation mode $sudo systemctl rescue # force rescue mode $sudo systemctl emergency # force emergency rescue mode

Here's a brief introduction to the difference between pause mode and hibernation mode.

Suspend: the pause mode saves the state of the system to memory, and then shuts down most of the system hardware, without actually shutting down, of course. When the user presses the button to wake up the machine, the system data will be recovered from memory, and then redrive the hardware that has been mostly turned off, so the wake-up system is faster.

Hibernate: hibernation mode is to save the system state to the hard disk, and then shut down the computer after it has been saved. When the user tries to wake up the system, the system starts to run normally and then recovers the system state saved on the hard disk. Because the data needs to be read from the hard disk, the wake-up speed is slow (if you are using a SSD disk, the wake-up speed is also very fast).

Check for dependencies between unit

Many services have dependencies, and one of the highlights of systemd is that it can manage the dependencies between unit. We can view the dependencies between unit with the following command:

Systemctl list-dependencies [unit] [--reverse] option-- reverse retraces who is using the unit.

Let's take a look at the dependencies of the currently running target:

We are currently running under graphical.target, which consists of a long list of dependencies (the figure does not show all the projects), the most important of which is multi-user.target. Let's use the-- reverse option to see who uses multi-user.target unit:

$systemctl list-dependencies multi-user.target-reverse

From the above two diagrams, we can determine the following relationship: graphical.target depends on multi-user.target.

We only show you how to view the dependencies between unit through target unit, and it is more important to check the dependencies between service unit in practice.

Related directories and files

The systemd-related file paths may be different in different distributions. To emphasize, this article introduces ubuntu 16.04.

/ lib/systemd/system/ most of the unit configuration files are placed in this directory.

Scripts generated during the operation of the / run/systemd/system/ system, such as user-related scripts and session-related scripts.

The main files in the / etc/systemd/system/ directory point to the linked files in the / lib/systemd/system/ directory.

Note that when we create our own unit configuration file, we can put the configuration file either in the / lib/systemd/system/ directory or in the / etc/systemd/system/ directory.

The / etc/default/ directory places default configuration files for many services.

/ var/lib/ some services that generate data will write its data to the / var/lib/ directory, for example, docker-related data files are placed in this directory.

The / run/ directory places a lot of temporary data about the service runtime, such as lock file, PID file, and so on.

We know that systemd manages a lot of services that use native socket, so there are bound to be a lot of socket files in the system. So, where are these socke files stored? We can use systemctl to view:

$systemctl list-sockets

In fact, the vast majority of socket files are stored in the / run directory and its subdirectories.

Systemctl daemon-reload subcommand

Daemon-reload is an easily misused subcommand, mainly because the word daemon contained in its name can easily confuse it with the reload subcommand.

In the previous article, we briefly introduced the reload subcommand, which reloads the configuration file of a service program. The program here refers to the program specified in the configuration of the service type unit, which is often referred to as daemon (an application that provides a service). For example, the unit prometheus.service of the service type, the daemon program that provides the service is / usr/local/share/prometheus/prometheus on my machine, so the reload subcommand reloads the configuration file of prometheus.

If you understand daemon in the daemon-reload subcommand as a systemd program, you can interpret this command as reloading the configuration file of the systemd program. All unit configuration files exist as configuration files for systemd programs. The conclusion drawn from this is:

When you add a new unit configuration file, you need to execute the daemon-reload subcommand. When the configuration file of unit changes, you also need to execute the daemon-reload subcommand.

The daemon-reload command does a lot of things, one of which is to regenerate the dependency tree (that is, the dependency between unit), so it won't take effect if you don't execute the daemon-reload command if you modify the dependency in the unit configuration file.

If you want to have a more systematic and in-depth study of linux commands, you can refer to the Linux Command Quick search Manual PDF, the third Chinese edition of this classic book.

Summary

Systemctl provides a number of subcommands for managing systemd and system services. This article just gives a brief introduction to the main subcommands and some common uses. For such a huge command set and believe that only in the use of continuous training can really master them.

The above is the whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.

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.