Detailed description of systemd Service

Systemd is an init software in Linux. It is developed by Lennart Poettering and is released open-source under lgpl 2.1 and later versions. Its development goal is to provide a better framework to represent the dependency between system services, and to achieve parallel startup of services during system initialization and reduce the system overhead of shell, the System V and BSD init programs are replaced.
The traditional system V is a serial start, that is, before starting the next script, the previous script must be executed completely, which will cause a great waste of time. In this age of time and money, such startup methods will surely be eliminated. First, ubuntu was the first to reverse the attack and enabled its upstart method. upstart was triggered based on events, but it was still started in serial mode, but it would not start for services that were not necessary.
At this time, systemd emerged. The main advantage is the parallel startup, which saves the startup time. The author of systemd spoke about it and started it up to 2 seconds.
Compared with the previous system V boot method, the following optimizations are available:

• Socket-activated and bus-activated services are used to improve the Parallel Running Performance of each dependent service;
• Cgroups instead of PID is used to track processes, so that even the daemon generated after two forks will not be out of the control of systemd.

 
1. After the kernel is started, the first process to be executed is/sbin/init.
If you want to start it in systemd mode, the first process that the kernel executes is/lib/systemd or/usr/lib/systemd.
Enter init =/lib/systemd on the grub interface.

 

Ii. After systemd is started, the corresponding configuration files are first located in the three directories, and the priorities are/etc/systemd/,/usr/lib/systemd/
And/lib/systemd/, the configuration file with a higher priority will overwrite the configuration file with a lower priority.

3. The configuration file of systemd is also called the unit file, which mainly includes the following types:

1. service: Daemon startup, stop, restart, and reload are the most obvious types in this unit.
2. socket: This type of unit encapsulates a socket in the system and the Internet. Currently, systemd supports af_inet, af_inet6, and af_unix socket for streaming, datagram, and continuous packets. It also supports the traditional OS transmission mode. Each socket unit has a corresponding service unit. The corresponding service is started when the first "connection" enters the socket or FIFO (for example, nscd. Socket starts nscd. Service after a new connection ).
3. device: This type of unit encapsulates a device that exists in the Linux Device Tree. Every device marked with the udev rule will appear as a device unit in systemd. Udev attribute settings can be used as the configuration source for configuring unit dependencies of devices.
4. mount: This type of unit encapsulates a mount point in the system structure hierarchy.
5. automount: This type of unit encapsulates a self-mount point in the system structure hierarchy. Each self-mount unit corresponds to a mounted Mount unit (it must be mounted as early as possible when the self-mount directory can be accessed ).
6. target: This type of unit is logically grouped by other units. They do not actually do anything, but reference other units. In this way, the Unit can be controlled in a unified manner. (For example, the multi-user.target is equivalent to running the 5most Bluetooth related th.tar get in the system that traditionally uses sysv only when the Bluetooth adapter is available to call Bluetooth-related services, such as: Bluetooth daemon, OBEX daemon, etc)
7. snapshot: Similar to target unit, the snapshot itself does not do anything. The only purpose is to reference other units.

4. The first unit file started by systemd is/lib/systemd/system/default.targetfile (the default.tar get file here is generally a link file.
In this example, default.tar get points to different files, which can reach different startup levels)

Example:
As you can see, default.targetrefers to the graphical.targetfile, and graphical.tar get indicates the graphic interface level.
Graphical.tar get the following content:

Description =: some descriptions, which are displayed on the user interface. They can be any string, which is generally about the service description.

Documentation =: Specifies the list of reference documents.
Requires =: indicates that graphical.targetdepends on multi user.target. if graphical.tar get is activated
The multi-user.tar get service will also be activated. Otherwise, if the multi-user.targetservice after requires is stopped or cannot be started, graphical.tar get
The Service will also stop. This option can be specified multiple times, so that all specified services are activated. After =: After the worker starts multiouser.target, start graphical.tar get. Before =: After starting this service, start before.
.
Conflicts =: configure a dependency conflict. When the rescue.targetservice is started, the graphical.targetservice stops and the graphical.tar get service starts,
Then rescue.tar GE will stop.
Wants =: relatively weakened requires =, display-manager.tar get will be started, but if it cannot be started or cannot be added to transaction processing, it does not affect
The graphical.tar get service is started as a whole.
Allowisolate =: Boolean value. If it is a true value, the service can use the systemctl isolate command to perform operations. Otherwise, the operation is rejected. The default value is false. Alias =: the alias to be used during installation. The name must have the same suffix (that is, the same type) as the service itself ). This option can be specified multiple times, all
When the systemctl enable command is executed, a considerable link is established.

5. Common commands
Description =: some descriptions, which are displayed on the user interface. They can be any string, which is generally about the service description.
Documentation =: Specifies the list of reference documents, in the URI format separated by spaces, such as http: //, https: //, file:, Info:, man :, this is ordered. It is best to first explain what the purpose of this service is, then how it is configured, and then other files. This option can be specified multiple times, multiple rows are merged. If an empty value is specified, this option is reset, and the previous configuration does not work.
Requires =: specify other services on which this service depends. If this service is activated, the services following requires will also be activated. Otherwise, if the services following requires are stopped or cannot be started, the Service will also stop. This option can be specified multiple times, so that all specified services are activated. Note that this option does not affect the order of start or stop. The order of start is configured using the after = and before = in a single sentence. For example, if Foo. service depends on bar. serivce, but only requires = and no after = or before =, then Foo. the Foo. service and bar. service. Generally, it is better to use wants = instead of requires = because the system will better handle service failures. Note that this dependency can also be processed outside the file, that is, the. Requires/directory is used. For more information, see the preceding description.
Requiresoverridable =: similar to the above requires =, however, in this case, as long as the user explicitly requires it to start, it will affect the dependent service, or the service will have an error or something, the startup of the dependent service is not affected.
        Requisite=, Requisiteoverridable =: similar to the preceding two. However, if the specified service is not started, the dependent service will not start and will fail immediately.
 Wants =: relatively weakened requires =. The services listed here will be started. However, if the services cannot be started or cannot be added to transaction processing, the service will not be started as a whole. This is a recommended method for associating two services. This dependency can also be added through the. Wants/directory in addition to the configuration file. For details, refer to the above description.
Bindsto =: similar to requires =, but in this case, if the services listed below stop or crash, the Service will also stop at the same time. Partof =: Another option similar to requires =, but it is restricted to stopping or restarting the service. If the service listed here is stopped or restarted, the Service will also be stopped or restarted. Note that this dependency is intended, that is, the service is stopped or restarted, and does not affect the running status of the service listed here.
Conflicts =: configure a dependency conflict. If some items are configured, when a service is started, or the services listed here are stopped, if the listed services are started, the service will be stopped, that is, it will only take effect after being started. Note that this setting is independent from after = and before =. If service a conflicts with service B and starts at the same time when service B starts, the startup may fail (both are required) or modify it to fix it (either or both of them are not required). In the latter case, unnecessary dependencies are deleted or conflicts are stopped.
        Before=, After =: configure the startup sequence between services, such as a foo. the service contains a line of before = bar. when they start at the same time, bar. service will wait for foo. the service is started after it is started. Note that this setting is independent of requires = and contains both after = and requires =. This option can be specified more than once. In this case, all startup is performed in order.
 Onfailure =: list one or more services. Activate these services when the service is in the failed status.
        PropagatesReloadTo=, Reloadpropagatedfrom =: These two lists some services. When other services reload, reload the service at the same time, or vice versa.
 Requiresmountsfor =: List of absolute paths separated by spaces, which is the specified path to be accessed by the mount file in the dependency of requires = and after =. Onfailureisolate =: it is a Boolean value. If it is true, onfailure = the subsequent services will enter the isolation mode, that is, all services that are not dependent on it will stop. If only one service is set, it can be placed after onfailure =. The default value is false. Ignoreonisolate =: A boolean value. If it is true, the service will not stop when it is isolated from other services (it does not understand what isolation means, probably later ). The default value is false.
Ignoreonsnapshot =: A boolean value. If it is true, the Service does not contain snapshots ). The default value is true for the device and snapshot services, and false for other services.  Stopwhenunneeded =: A boolean value. If it is true, the service will stop when the service is not in use. Note: In order to minimize the workload of systemd, services that are not used will not be stopped by default unless they conflict with other services or are explicitly required by the user. If this option is set, if no other active service requires this service, it will automatically stop. The default value is false.
        RefuseManualStart=, Refusemanualstop =: Boolean value. If it is set to true, the service can only be indirectly activated or stopped. In this case, the user can directly start or stop the service and will be rejected. Only other services can start or stop the service as other service dependencies. This is mainly to stop user misoperations. The default value is false.
Allowisolate =: Boolean value. If it is a true value, the service can use the systemctl isolate command to perform operations. Otherwise, the operation is rejected. The best way is not to change this option unless the target service acts like runlevels in the sysv startup system. It is just a preventive measure to avoid the state that the system cannot use. The default value is false.
Defaultdependencies =: Boolean value. If it is true (default value), some Default dependencies of this service will be established implicitly. The specific dependencies are determined by the service type. For example, for a common service (. service type), it will ensure that the service is started only after the basic system service is started, and the service is disabled before the system is shut down. In general, this should be set to false only when the service is started early and shut down later. Enable this option for most common services. If it is set to false, it will not disable all implicit dependencies, but only disable unnecessary ones.
 Jobtimeoutsec =: Specifies the timeout time when a client waits for a job of this service to complete. If the time limit is reached, the job will be canceled, but the service will not change the status, including entering the "failed" status. Except for the device service (that is, the. device type), the default value is 0 (that is, no timeout settings ). Note that this parameter is independent of the timeout settings set for a specific service (for example. the timeout =) set by the service type, which has no impact on the service itself, but the setting of a specific service has an impact (can be used to change the service status ).
ConditionPathExists=, ConditionPathExistsGlob=, ConditionPathIsDirectory=, ConditionPathIsSymbolicLink=, ConditionPathIsMountPoint=, ConditionPathIsReadWrite=, ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=, ConditionFileIsExecutable=, ConditionKernelCommandLine=, ConditionVirtualization=, ConditionSecurity=, ConditionCapability=, ConditionHost=, ConditionACPower=, Conditionnull =: This is a group of similar things. Check whether a specific condition is true. If it is not true, the service will be started slightly, but the dependent service will still run normally. If the test fails, the Service does not fail. The condition is checked when the service starts running.
 　　 ConditionPathExists=Is to check the existence status of the specified file when the service starts. If the specified absolute path name does not exist, the result of this condition is a failure. If the absolute path has! Prefix, then the condition is reversed, that is, the service is started only when the path does not exist. Conditionpathexistsglob = similar to the above options, but supports wildcards. Conditionpathisdirectory = determines whether the specified path is a directory. Conditionpathissymboliclink = determines whether the specified path is a link. Conditionpathismountpoint = determines whether the specified path is a mount point. Conditionpathisreadwrite = whether the specified path can be read and written for many years (that is, it is not mounted as a read-only system) conditiondirectorynotempty = checks whether the specified directory exists and is not empty. Conditionfilenotempty = checks whether the specified file is a regular file and is not empty (that is, the size is not 0 ). Conditionfileisexecutable = checks whether the specified file is a regular file and is executable. Similarly, conditionkernelcommandline = is used to determine whether a specified kernel command line startup parameter (or! Otherwise, this parameter must be a word or two words separated by =. in the previous case, you will find whether the Kernel Parameter has this word or the left side of the value assignment. In the latter case, both the left and right values must be assigned.
Conditioncondition alization = indicates whether a service is executed in a virtualized environment. This can be a Boolean value to determine if it is any virtualized environment, or one of the following strings: qemu, KVM, VMWare, Microsoft, Oracle, xen, bochs, chroot, openvz, lxc, lxc-libvirt, systemd-nspawn, to determine whether it is a specific virtualization environment, multiple nested virtualization environments, only determine the last layer. Available! To reverse the query.
Conditionsecurity = determines whether the system has enabled the security environment. Currently, only selinux, apparmor, And Smack. Available! To reverse the query.
 Conditioncapability = determines whether the capability bound to the service manager exists. (You can view details of other parts .) Set the name to capability, for example, cap_mknod. You can add it to the front! Reverse judgment.
Conditionhost = is used to determine whether the host name (hostname) or machine ID (machine ID) matches. You can add! Reverse.
Conditionacpower = determines whether the machine is using AC power. If it is set to true, the result is true only when at least one AC power supply is connected. If it is set to false, the result is true if no AC power is connected.
Finally, conditionnull = is a constant-type judgment condition. It should be a Boolean value. If it is set to false, the condition will always fail, and the condition will always be true.
If multiple conditions are specified, all conditions must be true (that is, the relationship between conditions is and ). A | symbol can be added before a condition. When a condition becomes a trigger condition and the service defines a trigger condition, when other non-trigger conditions and the trigger condition are met, the service will be executed at least once. Specify | and! at the same time! When prefix is used, it is processed first !. Except conditionpathissymboliclink =, all other conditions follow the link. If these conditions are null, they are reset, and any of the preceding settings no longer work. Sourcepath =: Path of the configuration file generated by the Service. This is mainly used to convert the format of the configuration file generated by the generation tool from the external configuration file to the configuration format of the local service. Therefore, do not use this option for general services.


The service file may also contain a [install] segment, which contains the installation information of the content service. It is not used during running of systemd. It is only useful when you use the systemctl enable and systemctl disable commands to enable/disable services. Alias =: the additional name (alias) that should be used during installation ). The name must have the same suffix (that is, the same type) as the service itself ). This option can be specified multiple times, and all names work. When the systemctl enable command is executed, a considerable link is established.
        WantedBy=, Requiredby =: In.wants/Or.requires/Create a link for the service in the subdirectory. The effect of this operation is that when the service in the list is started, the Service will also start. In bar. Service, wantedby = Foo. Service and alias = Foo. Service. Wants/bar. service basically mean one thing.
Also =: additional services to be installed when this service is installed.If this item is configured in the Service requested to be installed, the system CTL enable command automatically installs the service specified in this item.

Using these strings in the [install] segment has specific meanings: % N, % N, % P, % I, % u, % u, % m, % H, % B. for more information, see the next section. ,

Special string

Many settings support special strings that can be replaced with specific content during running or loading. The following table lists supported strings.

String	Introduction	Details
%n	Complete service name
%N	Complete service name without escaping
%p	Prefix name	For the instantiated service, this is the part before @. For other services, it refers to removing the suffix (that is, the type.
%P	Unescaped prefix name
%i	Instance name	For instantiated services, this refers to the part between @ and suffix.
%I	The instance name that is not escaped.
%f	Unescaped file name.	This can be an unescaped Instance name (if available) or prefix name with A/prefix.
%c	Service Control Group Path .?
%r	The root control group path of systemd .?
%R	Parent directory of the systemd root control group path.
%t	The socket directory during running.	This can be/run(System Manager) or$XDG_RUNTIME_DIR(User Manager ).
%u	User Name	This is the service configuration user or the user who runs the instance using systemd (if not configured ).
%U	User uid	This is the UID of the service configuration user or the UID of the instance running using systemd (if not configured)
%h	User home directory	This is the user's home directory configured for the service or the user's home directory for running instances using systemd (if not configured)
%s	User Shell	This is the User Shell configured for the service or the User Shell that runs the instance using systemd (if not configured)
%m	Machine ID	The machine ID of the running system. The format is a string.
%b	Startup ID	The startup ID of the running system. The format is a string ..
%H	Host Name	Host Name of the running system.
%%	Escape %	A single percentage.

Systemd manual page: http://www.freedesktop.org/software/systemd/man

Systora systemd description page:

Unbuntu systemd page: https://wiki.edubuntu.org/systemd

Arch release EMD description page: release (% E7 % AE % 80% E4 % BD % 93% E4 % B8 % ad % E6 % 96% 87)

Detailed description of systemd Service