directory

• In front

• systemd and systemctl

• Directory of the systemd configuration file

• Main service function types

• Service status

• Common instructions

Switch system mode (text, interface mode, etc.)

• Set the systemctl configuration file

---

• In front

I find systemCTL is really very useful things, feeling that using this mechanism can help us to solve a lot of problems, before did not care about this, now think of systemCTL this mechanism to comb through, and then the related common commands to sort out, then let’s have a good understanding of systemCTL.

• systemd and systemctl

We need to know about Systemd when we talk about systemctl, because There are two ways to manage Linux services: service and systemctl. Systemd is the latest init of the Linux system. It is used to speed up the system startup by starting as few processes as possible and concurrently starting as many processes as possible. The process management command of systemd is systemctl. It is worth mentioning that systemctl is compatible with service.

Here’s a quick overview of the benefits of systemd’s startup service management mechanism (and the benefits of using systemctl commands).

• Speed up the startup process by processing all services in parallel: The old init startup script (System V’s) was a “task by task” mode, so non-dependent services had to wait one by one. Systemd allows all services to start at the same time. After all, most of our hardware host systems and operating systems today support multi-core architectures, so you’ll find that the system starts faster.
• On-demand startup mode: Systemd Has only one SystemD service and the systemCTL instruction for processing, and no additional instructions are required. Unlike systemV, init, chkconfig, service… And so on. In addition, systemd is resident in memory, so any on-demand task can be immediately processed by subsequent daemons;
• Service affinity self-check: Since Systemd does its own service affinity check, if you manually start service B without starting service A, systemd automatically starts service A.
• Sorting by daemon functions: Systemd manages many daemons. To clarify the functions of all services, systemd first defines all services as a service unit (” Unit “) and classifies them into different service types. Systemd divides service units into service, socket, target, path, snapshot, timer, and other types.
• Grouping daemons: Systemd sets up a collection of daemons into a so-called Target project. This project is used to create a design environment, so a collection of daemons (executing a target is executing multiple daemons).
• Downward compatibility with older Init service scripts: Basically, Systemd is an init-compatible startup script, so old init startup scripts can be managed through Systemd, too, only if you don’t use some of Systemd’s advanced features.

• Directory of the systemd configuration file

• /usr/lib/systemd/system/ : The main startup script configuration for each service is put here, similar to the previous /etc/init.d;
• /run/systemd/system/ : directory where service scripts generated during system execution are stored. These scripts have a higher priority than /usr/lib/systemd/system/.
• /etc/systemd/system/ : directory for storing the execution script created by the administrator based on the requirements of the host system. The execution priority is higher than /run/systemd/system/.

From the above functions and priorities, we can see that the configuration in the /etc/systemd/system/ directory determines whether the system will perform certain services, so there are a lot of link files in the directory. Under /usr/lib/systemd/system/, the actual systemd startup script configuration file is placed. So if you want to change the startup Settings of a service, go to /usr/lib/systemd/system/. /etc/systemd/system/ simply links to the correct execution script configuration file. So to see the execution script Settings, you should go to /usr/lib/systemd/system/.

• Main service function types

.service: Service unit: Mainly refers to system services, including local services and network services required by the server itself. Most commonly used services are of this type. Therefore, it is the most common type.

.socket: Socket service for data exchange of internal programs (Socketunit) : Mainly the inter-process communication (IPC) information transmission socket (Socketfile) function. This type of service usually monitors the flow of information through the slot, and when there is a link service through the slot, the user’s request is forwarded to the corresponding daemon according to the current state, if not already started, then the user’s request is forwarded. Services that use sockets are generally not used, so the startup time is usually slightly delayed. Generally used for native services more, such as our graphical interface a lot of software is through the socket to carry out the native program data exchange behavior.

Target: Execution environment type (target unit) : is actually a collection of units, such as multi-user. Target is actually a collection of services.

Mount: Services related to file system mounting (automount unit/mount unit) : For example, automatic mounting from the network, NFS file system mounting, and other program management related to file systems.

.path: Monitoring specific file or directory type (Path unit) : Some services need to monitor specific directories to provide sequence services. For example, the most common print service is to start the printing function by monitoring the print sequence directory. This is where the.path service type support is needed.

. Timer: Loop execution service (Timer Unit) : This is similar to Anacrontab, but it is provided by Systemd voluntarily, and is much more elastic.

• Service status

Here we can try the following command to see the current state of the ATD service. The command and results are as follows:

systemctl status atd.service
Copy the code

You can see that the highlighted one is not. That’s the current state of the service. So what are the common states of services? Here are some examples.

• Active (running) : Indicates that one or more programs are being executed in the system;
• Active (exited) : A service that is executed only once and ends normally. No program is currently executed in the system.
• Active (waiting) : Being executed but waiting for some other event to continue;
• Inactive: The service is not currently running.
• Dead: Program has been cleared;

Up here is the result, I circled a place, what is that? That is actually the startup state of the service program, which is also divided into the following states.

• Enabled: This daemon will be executed at startup;
• Disabled: The daemon will not be executed at startup.
• Static: the daemon cannot be started by itself (enable is not available), but it may be woken up by another enabled service (the service associated with the property);
• Mask: the daemon cannot be started because it has been forcibly logged out (not deleted). It can be changed back to its original state by using systemctlunmask.

• Common instructions

systemctl # list the units that are booted on the system

systemctl list-unit-files # List all installed units

systemctl list-units --type=service --all  List all items of type service, whether started or not

systemctl get-default  Enter the current machine default mode, such as graphical interface mode or text mode

systemctl isolate multi-user.target  Change the current operating environment to plain text mode and turn off the graphical interface

systemctl isolate graphical.target  Change the current operating environment to a graphical interface

systemctlpoweroff  # System shutdown

systemctl reboot   # Restart

systemctl suspend   # Enter pause mode

systemctl rescue   Force into rescue mode

systemctl hibernate   Enter sleep mode

systemctl emergency   Force into emergency mode

systemctl list-dependencies --reverse   Query what is associated with the current default target

systemctl list-dependencies graphical.target  # Query what is associated with the target in GUI mode

systemctl list-sockets   View the current socket service

systemctl show etcd.service   Check the detailed configuration of unit

systemctl mask etcd.service   # Disable a service

systemctl unmask etcd.service   Undisable a service
Copy the code

Switch system mode (text, interface mode, etc.)

Here I want to mention the target project in particular, which is related to the operation interface. After all, there are several common modes of target:

• Graphical. Target: Text plus graphical interface. This project already includes the following multi-user.target project;
• Multi-user. target: plain text mode;
• Rescue. Target: In cases where you cannot log in using root, Systemd will add an extra temporary system to boot, unrelated to your original system. At this point you can get root access to maintain your system. But this is an extra system, so you may need to move to the chroot to get your original system;
• Target: an error occurs in the emergency handling system. If the root login is required, rescue. Target cannot be used.
• Target: shutdown process;
• Target: You can set the number of tty items you need. If you want to reduce the number of tty items, you can modify the configuration file of this item.

• Set the systemctl configuration file

Sshd. service: sshd.service: sshd.service: sshd.service

Analyzing the above configuration file, we can roughly divide the entire setup into three parts, namely:

• [Unit] : a description of the Unit itself, and the Settings associated with other daemons, including Settings such as what services to start the Unit after;
• [Service], [Socket], [Timer], [Mount], [Path], etc. Each unit type must have its own set item. For example, sshd. Service. This project mainly in the specification of service startup script, environment configuration file name, restart mode, etc.
• [Install] : this project is to Install the unit into the target;

There are some rules in the configuration file that need to be explained:

• Setting items is usually repeatable. For example, I can repeat two After’s in the configuration file, but the later setting will replace the previous one. Therefore, if you want to set the value to zero, you can use a setting like “After=”, which means there is nothing After the equals sign of the item, and reset the setting to zero.
• If the setting parameter requires a “yes/no” item (Boolean), you can use 1,yes,true,on for start, and 0,no,false,off for close! Choose as you like;
• Blank line, beginning with # or; That line, all represent annotations;

There are many Settings details in each section, so let’s use a simple table to describe each item.

[Unit] section
Set the parameters	Parameter Description
Description	This is the simple description of the service that we give the administrator when we use SystemCtlList-units, and of course the description of the service when we use SystemCtlStatus.
Documentation	This project provides administrators with the ability to perform further file queries, which can be documented on: Documentation=http://www.
After	This is basically just a description of the order in which services are started. There is no mandatory requirement that the unit can be started only after the services are started. For example, the sshd.service file mentions net. target and sshd-keygen. Service After, but if these two units are not started and sshd.service is forcibly started, Sshd. service should still be able to start, unlike the setup for “Requires”.
Before	As opposed to After, it is best to start the service before the service is started. However, this is just a specification for the order in which services are started, not a requirement.
Requires	The unit will not be started if the previous daemon is not started.
Wants	“Requires” is the opposite of “Requires”. It specifies what services it is best to start after the unit, but the goal is to create an environment where users can easily navigate. Therefore, if the service following the Wants is not started, it does not affect the unit itself.
Conflicts	If the service following this project is started, then our unit itself cannot be started. If our unit is started, then the service after this project cannot be started, which is the conflict check.

Part [Service]
Set the parameters	Parameter Description
Type	Simple: The default value. The daemon is started by the command string ExecStart is connected to. After startup, the daemon lives in memory. Forking: Programs started by ExecStart extend other subroutines through Spawns to serve as the main service for this daemon. The native parent program terminates at the end of startup. Most traditional unit services, such as the WWW service HTTPD, fall into this category. When the HTTPD program runs too long and is about to die, Systemd will create another subroutine to continue running, and then remove the parent program. Oneshot: Similar to Simple, but this program ends when it is done and does not live in memory. Dbus: Similar to Simple, but the daemon must get a d-bus name before it can continue running! So when you set this project, you usually set BusName= as well! Idle: Similar to simple, it means that all the daemon’s work must be completed before it can be executed. This kind of daemon is usually boot up to the last to execute the service! The more important projects are probably Simple, Forking and Oneshot! After all, many services require subroutines (Forking) and many more actions only need to be performed once at startup (oneshot), such as file system checking and mounting etc.
EnvironmentFile	You can specify the environment configuration file for the startup script! For example, the configuration file of sshd.service is written to /etc/sysconfig/sshd! You can also use Environment= followed by several different Shell variables to give Settings!
ExecStart	You can specify the environment configuration file for the startup script! For example, the configuration file of sshd.service is written to /etc/sysconfig/sshd! You can also use Environment= followed by several different Shell variables to give Settings!
ExecStop	An instruction to shut down this service, relative to the execution of SystemCtlstop.
ExecReload	Instruction behavior related to SystemCtlReload
Restart	If Restart is set to 1, the daemon service will be started again after it is stopped. For example, if you log in using a text interface on TTy2, log out after you’ve finished, basically, tty2 is over. But you will see the screen will immediately generate a new TTy2 login screen waiting for you to log in! That’s what Restart does! Unless you use Systemctl to force the service to shut down, this service will continue to be created over and over again!
RemainAfterExit	When set to RemainAfterExit=1, then the service will try to start again once all the daemon’s programs have stopped. This is great for the Type=oneshot service!
TimeoutSec	How long do we have to wait to enter the “forced end” state if the service fails to “start or end normally” during startup or shutdown for some reason?
KillMode	It can be either process,control-group, or none. If it’s proces then only the main daemon terminates (the string following ExecStart). If it’s control-group, All other control-groups created by the daemon will also be shut down. If none, no program will be closed.
RestartSec	If the service is shut down and then needs to be restarted, how long will it sleep to Restart? The default is 100ms (milliseconds).

Part [Install]
Set the parameters	Parameter Description
WantedBy	This setting is mostly followed by *.targetunit! This unit was originally attached to which targetunit! In general, most service units are attached to multi-user.target!
Also	When the current unit itself is enabled, the unit followed by Also is enabled. The services that have dependencies can be written here.
Alias	Make a link to the alias meaning! This service creates link files when systemctlEnable is associated with the service! In the case of multi-user.target, this partner is used as the plan for the default operating environment default.target, so when you set it to default. The/etc/systemd/system/default. The target will link to/usr/lib/systemd/system/multi – user. The target.