SYSTEMD Introduction to process management tools in Linux systems

SYSTEMD is an init software under Linux, led by Lennart Poettering, and open source under LGPL 2.1 and its subsequent version license. Lennart is a Redhat employee, but SYSTEMD is not a Redhat project. Its development goal is to provide a better framework to represent the dependencies between system services, and to implement the parallel startup of the service when the system is initialized, and to reduce the shell's overhead, and ultimately replace the System V and BSD-style init programs that are now commonly used.

Systemd This name derives from a convention in Unix: "D" is often used in Unix as the suffix identifier of the system daemon (English: Daemon, also known as background process). In addition, SYSTEMD is also the term D system of metonymy, which is used to describe a person's ability to adapt quickly to the environment and solve difficulties.

SYSTEMD is designed to improve Sysvinit's shortcomings and to compete with Ubuntu's upstart technology. Many of Systemd's concepts come from Apple's launchd. The goal is to start as few processes as possible, and to start as many processes as possible (this is the idea base for performance over Sysvinit). SYSTEMD to minimize the reliance on shell scripts. Traditional sysvinit use Inittab to decide which shell scripts to run, and the heavy use of shell scripts is considered to be inefficient and not parallel. SYSTEMD uses Linux-specific technology, no longer takes into account POSIX compatibility, as long as it can meet the needs of social change, break through some of the possible outdated technical constraints, which is also the need of today's creation, believe that the market will be judged.

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

The use of socket-activated and bus-activated service to improve the performance of each of the services of mutual dependence of the parallel operation;

The cgroups replaces the PID to track the process, so the daemon, even after two fork, will not be out of systemd control.

From the design idea, because SYSTEMD uses the Cgroup and fanotify and so on to realize its characteristic, therefore only applies to the Linux. In view of this, software sources based on the KFREEBSD branch cannot be included in Systemd.

Most mainstream distributions have either been systemd or are about to be introduced in the next release (such as Debian and Ubuntu). In this tutorial, we use a preview version of Fedora 21, which is already SYSTEMD's excellent experimental site, but no matter which distribution you use, the commands and considerations should be the same. This is a bonus point for SYSTEMD: It eliminates many subtle and trivial differences between different distributions.

Enter PS Ax in terminal | grep Systemd, 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 detects the hardware and organizes the memory, it runs the/USR/LIB/SYSTEMD/SYSTEMD executable program, which in turn initiates the other programs. (In the absence of SYSTEMD, the kernel will run/sbin/init, which will then run the rest of the various startup scripts in a system called Sysvinit.) )

The core of SYSTEMD is a concept called Unit units, which is a configuration file that contains information about service services (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 programs that need to be created at a certain mount point or when a device is plugged in, SYSTEMD can make it easy to work. (In the days without systemd, it's pretty ugly to use your feet to make these things right.) To list all the units on your Linux system, enter the following command:

Copy Code

The code is as follows:

Systemctl List-unit-files

Now, Systemctl is the primary tool for interacting with SYSTEMD, and it has a number of options. In the list of cells, you'll notice that there are some formatting: the cells that are enabled are shown as green, and the disabled disabled are displayed in red. Cells labeled "Static" are not directly enabled, they are objects that other cells rely on. To restrict the output list to include only services, use the following command:

Copy Code

The code is as follows:

Systemctl List-unit-files--type=service

Note that a unit is displayed as "enabled" and does not mean that the corresponding service is running, but only that it can be opened. To obtain information about a particular service, for example, in GDM (Gnome Display Manager), enter the following command:

Copy Code

The code is as follows:

Systemctl Status Gdm.service

This command provides a number of useful information: a description of the service, the location of the cell configuration file, the time of startup, the process number, and the cgroups that it is dependent on to limit the resource overhead of each group process.

If you go to see the unit profile located in/usr/lib/systemd/system/gdm.service, you can see various options, including the binaries to be run (the "Execstart" line), and other conflicting units ( That is, it is not possible to get into a running unit at the same time, and the unit that needs to go into operation before this unit is executed (the "after" line). Some units have additional dependency options, such as "Requires" (Necessary dependencies) and "wants" (optional dependencies).

Another interesting option here is:

Copy Code

The code is as follows:

Alias=display-manager.service

When you start Gdm.service, you will be able to view its status by Systemctl status Display-manager.service. This option is useful when you know there is a display manager running and want to do something about it, but you don't care what it is GDM,KDM,XDM or something else. Display the management program.

Targeted target Lock

If you enter the LS command in the/usr/lib/systemd/system directory, you will see a variety of files ending with. Target. Starting target targets is a way of aggregating multiple units together so that they start at the same time. For example, there is a "multiuser multi-user" state for most Unix-like operating systems, meaning that the system has been successfully started, the background service is running, and is ready for one or more users to log in and work-at least in text mode. (other states include the single user Single-user state used for administrative work, and the restart reboot state for the machine shutdown.) )

If you open a Multi-user.target file, you may expect to see a list of the units to be started. But you'll find that the file is almost empty--in fact, a service will make itself dependent on the Wantedby option to start the target. So if you're going to open avahi-daemon.service, Networkmanager.service and other. Service files, you'll see this line in Install section:

Copy Code

The code is as follows:

Wantedby=multi-user.target

Therefore, switching to a multiuser startup target will enable those cells that contain the above statement to be enabled. There are other startup targets available (for example, Emergency.target provides a shell for emergency use, and halt.target for machine shutdowns), and you can easily switch between them in the following ways:

Copy Code

The code is as follows:

Systemctl Isolate Emergency.target

In many ways, these are very much like run-level runlevel in sysvinit, such as the multi-user.target of text patterns similar to the 3rd run level, graphical.target similar to the 5th run level, Reboot.target Similar to the 6th run level, and so forth.

Open and stop

Now you may be immersed in meditation: we have seen so much, but still do not see how to stop and open the service! There is a reason for that. From the outside, the systemd may be complex and difficult to control like a beast. So before you start fiddling with it, it's important to look at how it works from a macro perspective. The commands that are actually used to manage services are simple:

Copy Code

The code is as follows:

Systemctl Stop Cups.service

Systemctl Start Cups.service

(If a cell is disabled, you can make it available by Systemctl enable plus the cell name.) This approach creates a symbolic link for the unit and places it in the. wants directory of the current startup target, which is in the/etc/systemd/system folder. Wants directory. )

There are also two useful commands for Systemctl restart and systemctl reload, followed by the cell name. The latter is used to let the unit reload its configuration file. Most of systemd have good documentation, so you can view the manual (man Systemctl) for details about each command.

Timer Unit: Replace Cron

In addition to system initialization and service management, SYSTEMD is also tapping into other aspects. To a large extent, it can do cron work, and it can be said to be in a more flexible way (with more readable syntax). Cron is a program that performs tasks at specified intervals-such as purging temporary files, refreshing caches, and so on.

If you enter the/usr/lib/systemd/system directory again, you will see that there are multiple. timer files. By using less to view these files, you will find that they have a similar structure to the. Service and. target files, but differ from [Timer] segments. As an example:

Copy Code

The code is as follows:

[Timer]

onbootsec=1h

onunitactivesec=1w

The ONBOOTSEC option tells Systemd to start the unit one hour after the system starts. The second option means that the unit is started once a week since then. There are a number of options for timers you can set, enter man systemd.time to view the complete list.

The SYSTEMD time precision defaults to one minute. That is, it runs the unit within a minute of the set time, but not necessarily the exact second. This is based on power management reasons, but if you need a timer that has no latency and is accurate to milliseconds, you can add the following line:

Copy Code

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 a dormant machine.

Log file: Say hello to Journald.

The second major part of Systemd is journal. This is a log system, similar to Syslog but has some notable differences. If you're a fan of the Unix log management model, be prepared to get out of the rage: This is a binary log, so you can't parse it with a regular command-line text processing tool. This design is not expected to cause a heated debate on the internet, but it does have some advantages. For example, a log can be organized more systematically with more metadata, making it easier to filter information based on executable file names and process numbers.

To view the entire journal, enter the following command:

Copy Code

The code is as follows:

Journalctl

Like many other SYSTEMD commands, this command directs the output through the pipe to the less program, so you can use the SPACEBAR to scroll down, type/(slash) lookup, and other familiar shortcut keys. You can also see a little color here, like red warnings and error messages.

The above command will output a lot of information. To limit its output to only the message that started this time, use the following command:

Copy Code

The code is as follows:

Journalctl-b

This is where SYSTEMD shine! Do you want to see all the messages since the last boot? Try Journalctl-b-1. The last one was replaced with 2-1. From a specific time, for example, October 24, 2014, since 16:38?

Copy Code

The code is as follows:

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

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

We can have a specific time to find the log accurately, that can be based on a specific program? For the unit, try this:

Copy Code

The code is as follows:

Journalctl-u Gdm.service

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

Copy Code

The code is as follows:

Journalctl _pid=890

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

Copy Code

The code is as follows:

Journalctl/usr/bin/pulseaudio

If you want to limit the output message to a priority, you can use the-P option. An option argument of 0 will only show an emergency message (that is, it is time to pray to $DEITY) (LCTT: $DEITY is a computer humor, deity refers to the broad sense of "God", the $ prefix means that this is a variable), for 7 will display all messages, Includes debug messages. Check out the manual (man Journalctl) For more information on priority.

It is worth noting that you can also combine multiple options to see messages that have a priority of less than or equal to 3 in the current startup by GDM service, use the following command:

Copy Code

The code is as follows:

Journalctl-u gdm.service-p 3-b

Finally, if you just want to open a terminal window that continues to update with journal, just as you do with the tail command when there is no systemd, enter Journalctl-f.

A Life without systemd?

If you are completely unable to accept SYSTEMD, you still have some choices in the mainstream distribution. In particular, Slackware, the oldest distribution, has not yet changed, but its main developers have not removed it from future planning. Some of the less famous distributions are also insisting on using Sysvinit.

But how long will this last? Gnome is increasingly reliant on systemd, and other mainstream desktop environments will follow suit. This is also causing a panic in the BSD community: SYSTEMD is tightly linked to the Linux kernel, causing the desktop environment to be increasingly inaccessible to some extent. A compromise solution might come in the form of a USELESSD (http://uselessd.darknedgy.net): A cropped version of the SYSTEMD that focuses purely on initiating and monitoring processes without consuming the entire underlying system.