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

This article mainly introduces "how to view the process management tool SystemD in the Linux system". In the daily operation, I believe that many people have doubts about how to view the process management tool SystemD in the Linux system. The editor consulted all kinds of materials and sorted out a simple and easy-to-use method of operation. I hope it will be helpful to answer the doubt of "how to view the process management tool SystemD in the Linux system". Next, please follow the editor to study!

SystemD is a kind of init software under Linux, which is developed by Lennart Poettering and released under the license of LGPL 2.1 and subsequent versions. Lennart is an redhat employee, but SystemD is not a redhat project. Its development goal is to provide a better framework to express the dependency relationship between system services, and to realize the parallel startup of services during system initialization, at the same time, to reduce the system overhead of Shell, and finally replace the commonly used System V and BSD style init programs.

The name SystemD comes from a convention in Unix: "d" is often used in Unix as the suffix identification of the system daemon (English: daemon, also known as background process). In addition, SystemD is also borrowed from the English term D system, which is used to describe a person's ability to adapt quickly to the environment and solve difficulties.

SystemD is designed to improve the shortcomings of SysVinit and compete with Ubuntu's upstart. Many of the concepts of SystemD come from Apple's launchd. The goal is to start as few processes as possible; start as many processes in parallel as possible (this is the basis of the idea that performance is better than SysVinit). SystemD minimizes its reliance on Shell scripts. Traditional SysVinit uses inittab to decide which Shell scripts to run, and heavy use of Shell scripts is considered to be inefficient and unable to run in parallel. SystemD uses Linux proprietary technology, no longer taking into account POSIX compatibility, as long as it can meet the needs of social change and break through some technical constraints that may be outdated, which is also the need of today's credit concept. I believe the market will judge it.

Compared to the System V-style init used by most distributions, SystemD adopts the following new technologies:

Adopt Socket-activated and bus-activated services to improve the parallel performance of interdependent services

Use cgroups instead of PID to track progress, so even daemons generated after two fork are not out of systemd's control.

Conceptually, because SystemD uses components such as cgroup and fanotify to implement its features, it is only applicable to Linux. In view of this, software sources based on kFreeBSD branches cannot be incorporated into SystemD.

Most major distributions have either adopted Systemd or are about to adopt it in the next release (such as Debian and Ubuntu). In this tutorial, we use a preview version of Fedora 21, which is already an excellent lab site for Systemd, but no matter which distribution you use, the commands and considerations should be the same. This is an added point of Systemd: it eliminates many subtle and trivial differences between different distributions.

Type ps ax | grep systemd in the terminal and see the first line, where the number 1 indicates that its process number is 1, which means it is the first program initiated by the Linux kernel. Therefore, once the kernel has detected the hardware and organized the memory, it runs the / usr/lib/systemd/systemd executable program, which initiates other programs in order. In the days before Systemd, the kernel would run / sbin/init, and then the program would run the rest of the startup scripts on a system called SysVinit. )

At the core of Systemd is a concept called unit unit, which are configuration files that store information about service service (programs running in the background), devices, mount points, and other aspects of the operating system. One of the goals of Systemd is to simplify the interaction between these things, so if you have a program that needs to be created at a mount point or after a device is plugged in, Systemd can make it quite easy to make it work. (in the days without Systemd, it would be quite ugly to use scripts to put these things together. ) to list all units on your Linux system, enter the following command:

The code is as follows:

Systemctl list-unit-files

Today, systemctl is the main tool for interacting with Systemd, and it has a number of options. In the list of cells, you will notice that there is some formatting here: the cells with enabled enabled are shown in green, and the cells with disabled disabled are shown in red. Cells marked "static" cannot be enabled directly; they are objects on which other units depend. To restrict the output list to include only services, use the following command:

The code is as follows:

Systemctl list-unit-files-type=service

Note that the display of a unit as "enabled" does not mean that the corresponding service is running, but that it can be turned on. To get information about a particular service, take GDM (Gnome Display Manager) as an example, enter the following command:

The code is as follows:

Systemctl status gdm.service

This command provides a lot of useful information: a description of the service, the location of the unit configuration file, the time it was started, the process number, and the CGroups to which it belongs (to limit the resource overhead of each group of processes).

If you look at the unit configuration file at / usr/lib/systemd/system/gdm.service, you can see a variety of options, including the binaries to be run (the "ExecStart" line), other conflicting units (that is, units that cannot be run at the same time), and the units that need to be run before this unit executes (the "After" line). Some units have additional dependency options, such as "Requires" (necessary dependencies) and "Wants" (optional dependencies).

Another interesting option here is:

The code is as follows:

Alias=display-manager.service

When you start gdm.service, you will be able to view its status through systemctl status display-manager.service. This option is useful when you know that there is a display manager display manager running and want to do something about it, but you don't care if it's GDM,KDM,XDM or some other display manager.

Target target lock

If you enter the ls command in the / usr/lib/systemd/system directory, you will see various files that end in .target. Starting a target target is a way to aggregate multiple units so that they start at the same time. For example, for most Unix-like operating systems, there is a "multi-user multi-user" state, which means that the system has been successfully started, the background service is running, and one or more users are ready to log in and work-- at least in text mode. Other states include the single-user single-user state for administrative work and the restart reboot state for machine shutdown. )

If you open the multi-user.target file to find out, you might expect to see a list of units to be started. But you'll find that the inside of the file is almost empty-- in fact, a service makes itself a dependency on the startup target through the WantedBy option. So if you open the avahi-daemon.service, NetworkManager.service, and other .service files, you will see this line in the Install section:

The code is as follows:

WantedBy=multi-user.target

Therefore, switching to the multi-user startup target enables enable units that contain the above statements. There are other boot targets available (for example, emergency.target provides a shell for emergencies and halt.target for machine shutdown), and you can easily switch between them in the following ways:

The code is as follows:

Systemctl isolate emergency.target

In many ways, these are similar to the runtime runlevel in SysVinit, such as multi-user.target in text mode is similar to runlevel 3, graphical.target is similar to runlevel 5, reboot.target is similar to runlevel 6, and so on.

Open and stop

Now you may be lost in thought: we've seen so much, but we still haven't seen how to stop and start the service! There is actually a reason for this. From the outside, Systemd may be complex and difficult to navigate like a beast. So before you start fiddling with it, it's necessary to look at how it works from a macro perspective. The actual command used to manage the service is very simple:

The code is as follows:

Systemctl stop cups.service

Systemctl start cups.service

(if a unit is disabled, you can first enable it by adding the cell name to systemctl enable. This creates a symbolic link for the unit and places it in the .launch directory of the current startup target, which is in the / etc/systemd/system folder. )

Two other useful commands are systemctl restart and systemctl reload, followed by the unit name. The latter is used to have the unit reload its configuration file. Most of the Systemd is well documented, so you can check the man systemctl for the details of each command.

Timer unit: replace Cron

In addition to system initialization and service management, Systemd is also involved in other aspects. To a large extent, it does the work of cron, and it can be said to be in a more flexible way (with a more readable syntax). Cron is a program that performs tasks at specified intervals-such as clearing temporary files, flushing caches, and so on.

If you enter the / usr/lib/systemd/system directory again, you will see that there are multiple .timer files there. Looking at these files with less, you will find that they have a similar structure to .service and .target files, except for the [Timer] section. For example:

The code is as follows:

[Timer]

OnBootSec=1h

OnUnitActiveSec=1w

The OnBootSec option tells Systemd to start the unit an hour after the system starts. The second option means: start this unit once a week since then. There are a number of options for timers that you can set. Enter man systemd.time to see the complete list.

The time precision of Systemd defaults to one minute. In other words, it will run the unit within one minute of the set time, but not necessarily to that second. This is for power management reasons, but if you need a timer that is accurate to milliseconds without any delay, you can add the following line:

The code is as follows:

AccuracySec=1us

In addition, the WakeSystem option (which can be set to true or false) determines whether the timer can wake up a machine in a dormant state.

Log files: say hello to journald

The second major part of Systemd is journal. This is a logging system, similar to syslog, but with some significant differences. If you're a fan of Unix log management mode, be prepared to get angry: this is a binary log, so you can't use regular command-line text processing tools to parse it. This design decision has unexpectedly caused heated debate on the Internet, but it does have some advantages. For example, logs can be more systematically organized with more metadata, making it easier to filter information based on executable file names, process numbers, and so on.

To view the entire journal, enter the following command:

The code is as follows:

Journalctl

Like many other Systemd commands, this command pipelines the output to the less program, so you can use the spacebar to scroll down, type / (slash) to find, and other familiar shortcuts. You can also see a few colors here, such as red warnings and error messages.

The above command outputs a lot of information. To restrict it from outputting only messages for this startup, use the following command:

The code is as follows:

Journalctl-b

This is where Systemd shines! Do you want to see all the messages since the last startup? Try journalctl-b-1. From the last time? Replace-1 with-2. What about since a specific time, such as 16:38 on October 24th, 2014?

The code is as follows:

Journalctl-b-since= "2014-10-24 16:38"

Even if you regret binary logging, it's still a useful feature, and for many system administrators, it's much easier to build similar filters than to write regular expressions.

We have been able to accurately find the log according to a specific time, can it be based on a specific program? For units, try this:

The code is as follows:

Journalctl-u gdm.service

(note: this is a good way to view the logs generated by X server. ) according to the specific process number?

The code is as follows:

Journalctl _ PID=890

You can even request to see only the messages generated by an executable:

The code is as follows:

Journalctl / usr/bin/pulseaudio

If you want to limit the output of messages to a certain priority, you can use the-p option. If the option parameter is 0, only urgent messages will be displayed (that is, it's time to pray to $DEITY) (LCTT: $DEITY is a computer humor, DEITY means "God" in a broad sense, and the $prefix indicates that this is a variable). If it is 7, it will display all messages, including debug messages. Please see the manual (man journalctl) for more information about priorities.

It is worth pointing out that you can also combine several options, and to view messages with priority levels less than or equal to 3 output by the GDM service in the current startup, use the following command:

The code is as follows:

Journalctl-u gdm.service-p 3-b

Finally, if you just want to open a terminal window that is constantly updated with journal, as you did with the tail command when there is no Systemd, type journalctl-f.

A life without Systemd?

If you just can't accept Systemd at all, you still have some options in mainstream distributions. In particular, Slackware, the oldest release, has not changed yet, but its main developers have not removed it from future plans. Some obscure distributions also insist on using SysVinit.

But how long will this last? Gnome is increasingly dependent on Systemd, and other mainstream desktop environments will follow suit. This is also the reason for the panic in the BSD community: Systemd is closely linked to the Linux kernel, making the desktop environment increasingly unportable to some extent. A compromise solution may come in the form of Uselessd (http://uselessd.darknedgy.net)): a tailored version of Systemd that focuses purely on starting and monitoring processes without consuming the entire underlying system.

At this point, the study on "how to view the process management tool SystemD in the Linux system" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.