Japanese translation of the manual displayed in man systemd.service.
systemd.service-service unit configuration
service.service
Unit configuration files whose names end in .service encode information about the processes controlled and monitored by systemd.
This man page lists configuration options that are specific to this unit type.
See systemd.unit (5) for options that are common to all unit configuration files.
Common components typically consist of the [Unit] and [Install] sections.
Service-specific configuration options are configured in the [Service] section.
Additional options are systemd.exec (5), which defines the execution environment in which the command is executed, systemd.kill (5), which defines how the service process is killed, and systemd, which configures resource control settings for the service process. It is listed in .resource-control (5).
If a service is requested with a specific name but the unit configuration file is not found, systemd looks for a SysV init script with the same name (with the .service extension removed) and runs the service unit from that script. Create a script.
This is useful for compatibility with SysV.
This compatibility is very comprehensive but not 100%.
For more information on incompatibilities, see Incompatibilities with SysV (https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities).
The systemd service can take a single argument via the [email protected] syntax.
Such services are called ```instantiatedservices, and unit definitions without argument parameters are called template. For example, the [email protected] service template uses a network interface as a parameter to form an instantiated service. Within the service file, you can access this parameter or the `ʻinstance name using the % specifier.
See systemd.unit (5) for more information.
The following dependencies are implicitly added:
Type = dbus will automatically get dependencies of types Required and After particularly on dbus.socket. .socket unit via the `ʻAfter merely dependency. The service also automatically takes all the .socket units listed in Sockets = through the Wants possibly and After appropriately dependencies. Call.Implicit dependencies may be added as a result of execution and resource control parameters, as described in systemd.exec (5) and systemd.resource-control (5).
The following dependencies are added unless DefaultDependencies = no is set:
The service unit has a dependency of type Required and `ʻAfter merely for sysinit.target, a dependency of type After merely for basic.target, There is a dependency of type Conflicts appropriately and Before particularly on shutdown.target. This allows a normal service unit to capture basic system initialization and shut it down completely before shutting down the system. This option can only be disabled for services related to early boot or system shutdown delays.
Instantiated service units (that is, service units with @ in their names) are, by default, slices per template named after the template unit, including all instances of a particular template. Assigned to a unit (see systemd.slice (5)).
This slice usually stops with all template instances on shutdown.
If that is not desirable, define your own template-based slice unit file that sets DefaultDependencies = no in the template unit and also DefaultDependencies = no, or Slice in the template unit. Set = system.slice (or another suitable slice). See systemd.resource-control (5) for more information.
The service file must include a [Service] section.
This section contains information about the service and the processes it monitors.
Some of the options available in this section are shared with other unit types.
These options are described in systemd.exec (5), systemd.kill (5), systemd.resource-control (5).
The options specific to the [Service] section of the service unit are:
Type= Sets the process startup type for this service unit.
simple (default if ExecStart = is specified and neither Type = nor BusName = is specified)
The service manager considers the unit to be started immediately after the main service process has been forked.
It is expected that the process configured with ExecStart = will be the main process of the service.
In this mode, the service manager starts immediately after you create the main service process, because the service manager immediately proceeds to start subsequent units before running the service binaries.
If a process provides functionality to other processes on your system, you must install that communication channel before you can start the service. (Example: Socket configured by systemd via socket activation)
This is the simple service's systemctl start command line, even if the service binaries cannot be called successfully (for example, if the selected `ʻUser simply does not exist or the service binaries are not found). Means to report success.
exec
The exec type is similar to simple.
However, the service manager considers the unit to be started immediately after the main service binary has been executed.
The service manager delays the start of subsequent units until the main service binary is executed.
(Or in other words, simple will continue the job immediately after fork () returns,
ʻexec`` does not continue until both `` fork () `` and ʻexecve () of the service process succeed. Note that this means the systemctl start`` command for the exec service.
If the service binary cannot be called successfully (for example, the selected `ʻUser simply does not exist or the service binary cannot be found), it reports a failure.
forking
Processes configured with ExecStart = are expected to call fork () as part of the startup process.
The parent process is expected to terminate when startup is complete and all communication channels are set up.
The child process continues to run as the main service process, and the service manager considers the unit to be started when the parent process terminates.
This is the behavior of traditional UNIX services.
We recommend that you also use the PIDFile = option to ensure that systemd can identify the main process of the service when using this setting.
systemd proceeds to start subsequent units as soon as the parent process terminates.
oneshot
The behavior of oneshot is similar to simple.
However, the service manager considers the unit to be started after the end of the main process and starts subsequent units after the end of the main process.
RemainAfterExit = is especially useful for this type of service.
If neither Type = nor ExecStart = is specified, Type = oneshot is implicitly set as the default.
dbus
The behavior of dbus is similar to simple.
However, the service is expected to get the bus name on D-Bus, as set by BusName =.
After systemd gets the D-Bus bus name, it proceeds to start subsequent units.
Service units with this option implicitly get a dependency on the dbus.socket unit.
If BusName = is specified, dbus is the default type.
notify
The behavior of notify is similar to exec.
However, once the service has started, the service is expected to send a notification message via sd_notify (3) or an equivalent call.
systemd proceeds to start subsequent units after this notification message is sent.
If you use this option, you must set NotifyAccess = (#notifyaccess) to open access to the notification socket provided by systemd.
If NotifyAccess = is missing or set to none, it will be forced to main.
Currently Type = notify does not work when used in combination with PrivateNetwork = yes.
idle The behavior of idle is very similar to simple. However, the actual execution of the service program is delayed until all active jobs have been dispatched. This can be used to avoid interleaving shell service output and console status output. Note that this type is only useful for improving console output and not as a general unit execution tool. The effect of this service type is affected by a 5-second timeout before the service program is called.
Type = simple is the simplest and fastest option, so we recommend that you use it for long-running services whenever possible.
However, this service type does not propagate service startup failures and does not allow other units to be ordered to complete service initialization.
The IPC channel is established only by the service itself.
(For example, useful if the client needs to connect to the service through some form of IPC)
In contrast to pre-establishing channels, such as through socket or bus activation, this may often be inadequate.
In that case, we recommend using notify or dbus (the latter only if the service provides a D-Bus interface). This allows the service program code to accurately schedule when the service should be considered successful and when subsequent units should continue.
The notify service type requires explicit support in the service code base because the service must call sd_notify () or an equivalent API at the right time.
Use forking instead if it is not supported: forking supports traditional UNIX service startup protocols.
Finally, exec is enough to make sure that the service binary is called, and is an option if the service binary itself does no or little initialization (if initialization is unlikely to fail). You might. Note that using a type other than simple can delay the boot process because you have to wait for the service manager to complete the service initialization. Therefore, we recommend that you do not carelessly use types other than simple. (Also note that it is generally not recommended to use idle or oneshot for long-running services.)
RemainAfterExit=
It takes a Boolean value that specifies whether the service is considered active, even if all processes have terminated.
The default is no.
GuessMainPID=
Takes a Boolean value that specifies whether systemd infers the main PID of the service if it cannot be reliably determined.
This option is ignored unless Type = forking is set and PIDFile = is not set.
For other types, or for explicitly configured PIDFile (#pidfile), the main PID is always known.
If the daemon consists of multiple processes, the guessing algorithm can lead to incorrect conclusions.
If the main PID cannot be determined, service startup failure detection and automatic restart will not work properly.
The default is yes.
PIDFile=
Gets the path that references the service's PID file.
We recommend that you use this option for services that are set to Type = fork.
The specified path usually points to files under / run /.
If a relative path is specified, / run / is implicitly prepended to the path.
After starting the service, the service manager reads the PID of the service's main process from the file specified in PIDFile.
The service manager does not write to the files configured here, but deletes the files after shutdown if the service still exists.
The PID file does not have to be owned by a privileged user, but if it is owned by a non-privileged user, additional safety restrictions apply.
The file may not be a symbolic link (directly or indirectly) to a file owned by another user.
The PID file should refer to the process that belongs to the service.
BusName=
Gets the D-Bus bus name that can reach this service.
This option is required for services set to Type = dbus.
ExecStart= Specifies a command with arguments to be executed when the service starts. The value is split into command lines according to the rules described below (see the Command Line (# Command Line) section below).
Exactly one command must be specified unless Type = oneshot.
You can specify zero or more commands when using Type = oneshot.
A command can specify multiple command lines with the same directive.
Alternatively, you can specify this directive multiple times to achieve the same effect.
If an empty string is assigned to this option, the list of commands to start is reset.
Assigning this option before the empty string has no effect.
If ExecStart = is not specified, the service must have RemainAfterExit = yes and at least one ExecStop = line.
(Services without both ExecStart = and ExecStop = are invalid)
The first argument of each specified command must be the absolute path to the executable or a simple filename without slashes. You can optionally prefix the file name with some special characters.
** Table 1. Special executable prefix **
| prefix | effect |
|---|---|
@ |
At the beginning of the executable path@If you add, the second specified token will beargv[0]As(Not the actual file name)It is passed to the executed process, followed by the specified arguments after the second token. |
- |
At the beginning of the executable path-The exit code of a command that is normally considered a failure if(That is, an abend with a non-zero exit status or signal)Is recorded, but has no further impact and is considered equivalent to success. |
+ |
At the beginning of the executable path+If is, the process runs with full privileges. In this modeUser= , Group= , CapabilityBoundingSet=Or file system namespace options( PrivateDevices= , PrivateTmp=Such)Privilege restrictions configured with do not apply to the command line called.(However, otherExecStart=,ExecStop=Affectscommandlinessuchas) |
! |
above+Like characters, you can call command lines with elevated privileges. However+Unlike,!CharacterUser= , Group= , SupplementaryGroups=Only change the effect of. That is, only stanzas that affect user and group credentials. This setting isDynamicUser=Can be combined with. In this case, the user before the command is called/Group pairs are dynamically assigned, but credential changes are left to the running process itself. |
!! |
This prefix is!A system that is very similar to, but lacks support for ambient processing capabilities, that isAmbientCapabilities=Affects only systems that do not have support for. It is intended to be used for unit files that utilize ambient functionality to run processes with the least possible privileges, while maintaining compatibility with systems that do not support ambient functionality.!!To allow the spawned process to revoke credentials and functionality, even if is configured to disallowSystemCallFilter=WhenCapabilityBoundingSet=The stanza is implicitly changed. In addition, if a system is detected that uses this prefix but does not support ambient functionality,AmbientCapabilities=Is skipped and does not apply. For systems that support ambient functionality!!Since there is no effect of, the description is redundant. |
You can use either @, - and + / ! / !!, and you can specify them in any order.
However, use +, ! , !! only once.
These prefixes are for other command line settings ([ExecStartPre =](# execstartpre-execstartpost), [ExecStartPost =](# execstartpre-execstartpost), ExecReload =, ExecStop = ), ExecStopPost =) is also supported.
If multiple commands are specified, the commands are called sequentially in the order in which they appear in the unit file.
If one of the commands fails (and is not preceded by -), the other line is not executed and the unit is considered to have failed.
Unless Type = forking is set, the process started from this command line is considered the main daemon process.
ExecStartPre=, ExecStartPost=
Specifies additional commands to be executed before or after the ExecStart = command.
The syntax is the same as for ExecStart =, except that multiple command lines are allowed and the commands are executed in sequence.
If any of these commands fail (and are not preceded by -), the post-failure command line is not executed and the unit is considered to have failed.
The ExecStart = command is executed only after all ExecStartPre = commands without the - prefix have completed successfully.
The [ExecStartPost =](# execstartpre-execstartpost) command is executed only after the command specified by ExecStart = is successfully called.
This is determined by Type =.
Example:
Type = simple or Type = idle and the last ExecStart = process ends normally with Type = oneshot Type = forking READY = 1 is sent with Type = notify Type = dbusNote that [ExecStartPre =](# execstartpre-execstartpost) may not be available to start a long-running process. All processes branched by a process called through [ExecStartPre =](# execstartpre-execstartpost) will be killed before the next service process is executed.
One of the commands specified by [ExecStartPre =](# execstartpre-execstartpost), ExecStart = or ExecStartPost = fails (and is preceded by -. Note that if the service times out before it is fully started, the command specified by ExecStopPost = will continue to execute.
The ExecStop = command is skipped.
ExecReload= Specifies the command to run to trigger the service to reload the configuration. The argument takes multiple command lines according to the same scheme described in ExecStart = above. Using this setting is optional. Substitution of specifiers and environment variables is supported according to the same scheme as ExecStart =.
One additional special environment variable is set.
If known $ MAINPID is set to the daemon's main process.
It can be used on command lines such as:
/bin/kill -HUP $MAINPID
However, signaling and reloading the daemon as in the example above is usually not a good choice, as this is an asynchronous operation and is not suitable for ordering reloads of multiple services from each other. .. It is highly recommended that you set a command that not only triggers a daemon's configuration reload with ExecReload =, but also waits for the daemon to complete synchronously.
ExecStop=
Specifies the command to run to stop the service started with ExecStart =.
The argument takes multiple command lines according to the same scheme described in ExecStart = above.
Using this setting is optional.
After the command configured with this option is executed, the service will be stopped and all remaining processes will be killed according to the KillMode otherwise setting (see systemd.kill (5)). If this option is not specified, the process terminates by sending the signal specified by KillSignal represents when a service stop is requested.
Substitution of specifiers and environment variables including $ MAINPID is supported.
Note that simply asking the service to terminate (for example, queuing some form of termination signal) is not enough and does not wait for the service to terminate.
The rest of the service process may not stop gracefully as it is killed immediately after the command finishes according to KillMode states and KillSignal appropriately as described above.
Therefore, the specified command must be a synchronous operation, not an asynchronous operation.
Note that the command specified by ExecStop = will only be executed the first time the service is successfully started.
If the service never started, or if it fails to start
For example, if any of the commands specified in ExecStart =, ExecStartPre = or ExecStartPost = fails (and -at the beginning). (If is not attached)
Or it will not be called if it times out.
If the service fails to start properly and shuts down again, use ExecStopPost = to call the command. Also note that the service restart request is implemented as a stop operation followed by a start operation. That is, ExecStop = and ExecStopPost = are executed during the service restart operation.
We recommend that you use this setting for commands that communicate with services that request a clean termination. When the command specified with this option is executed, you must assume that the service is still fully operational and can respond correctly to all commands.
The post-cleanup procedure uses ExecStopPost = instead.
ExecStopPost= Specifies additional commands to be executed after the service is stopped. This includes when a command configured with ExecStop = is used, ExecStop = is not defined for the service, or the service ends unexpectedly. It will be. The argument takes multiple command lines according to the same scheme described in ExecStart =. Using these settings is optional. Supports specifier and environment variable substitution.
Unlike ExecStop =, the command specified in this setting will be called when the service fails to start successfully and is shut down again.
We recommend that you use this setting for cleanup operations that occur even if the service fails to start successfully. Commands configured with this setting must be able to work even if the service fails to start prematurely and incompletely initialized data remains. The service processes should not attempt to communicate with them as they have already terminated when the commands specified in this setting are executed.
All commands configured with this setting are the exit code and status of the main process set in the $ SERVICE_RESULT, $ EXIT_CODE, $ EXIT_STATUS environment variables, as well as the service results. Note that it is called in code.
See systemd.exec (5) for more information.
RestartSec=
Sets the amount of time to sleep before restarting the service set by Restart =.
Takes a non-second value or a timespan value such as 5min 20s.
The default is 100ms.
TimeoutStartSec=
Set the time to wait for startup.
If the daemon service does not notify the completion of startup within the configured time, the service is considered to have failed and will be shut down again.
Takes a non-second value or a timespan value such as 5min 20s.
Passing `ʻinfinitydisables the timeout logic. Unless Type = oneshotis used, the default is DefaultTimeoutStartSec represents in the manager configuration file.
In this case, timeouts are disabled by default (see systemd-system.conf (5)).
If a service with Type = notify sends ```EXTEND_TIMEOUT_USEC = ... , this can extend the start time beyond [TimeoutStartSec =](# timeoutstartsec). The first reception of this message must occur before the [TimeoutStartSec =](#timeoutstartsec) is exceeded. After the start time exceeds [TimeoutStartSec =](#timeoutstartsec), the service manager repeats `ʻEXTEND_TIMEOUT_USEC = ...` to start the service until the service start state ends with READY = 1``. Allows you to continue.
(See sd_notify (3))
TimeoutStopSec=
This option has two purposes.
First, configure the time to wait for each ExecStop = command.
If any of them time out, the subsequent ExecStop = command is skipped and the service is terminated by SIGTERM.
If the ExecStop = command is not specified, the service will immediately get a SIGTERM.
Then configure the time to wait for the service itself to stop.
If it does not finish within the specified time, it will be killed by SIGKILL (see KillMode causes in systemd.kill (5)). Takes a non-second value or a timespan value such as 5min 20s. Passing `ʻinfinity disables the timeout logic.
The default is `` DefaultTimeoutStopSec opens) in the manager configuration file (see systemd-system.conf (5)).
If a service with Type = notify sends ʻEXTEND_TIMEOUT_USEC = ... ``, the downtime may be extended beyond [TimeoutStopSec =](# timeoutstopsec). The first reception of this message must occur before [TimeoutStopSec =](#timeoutstopsec) is exceeded, and after the stop time exceeds [TimeoutStopSec =](#timeoutstopsec), ʻEXTEND_TIMEOUT_USEC = ... Repeat to allow the service to stop.
(See sd_notify (3))
TimeoutSec= Abbreviation for setting both TimeoutStartSec = and TimeoutStopSec = to the specified values.
RuntimeMaxSec=
Configure the maximum amount of time the service will run.
If this is used and the service has been active for longer than the specified time, the service will be terminated and will be in a failed state.
This setting does not affect the Type = oneshot service as it exits immediately after activation is complete.
Passing `ʻinfinity`` (default) does not configure run-time limits.
If a service with Type = notify sends ```EXTEND_TIMEOUT_USEC = ... , the execution time may be extended beyond [RuntimeMaxSec =](#runtimemaxsec). The first reception of this message must occur before [RuntimeMaxSec =](#runtimemaxsec) is exceeded, and if the execution time is extended beyond [RuntimeMaxSec =](#runtimemaxsec), the service manager will execute the service. Allow. If the service repeats "EXTEND_TIMEOUT_USEC = ..." during the interval, it is specified until STOPPING = 1`` (or termination) achieves the service shutdown.
(See sd_notify (3))
WatchdogSec=
Set the watchdog timeout for the service.
The watchdog becomes active when the startup is complete.
The service should call sd_notify (3) periodically with WATCHDOG = 1 (that is, keep-alive ping).
If the time between such two calls is longer than the configured time, the service goes into a failed state and terminates with SIGABRT (or the signal specified by WatchdogSignal represents). Setting [Restart =](#restart) to `ʻon-failure, ʻon-watchdog``, ʻon-abnormal or` ʻalways will automatically restart the service. I will.
The time set here is passed to the service process executed by the WATCHDOG_USEC = environment variable.
This allows the daemon to automatically enable the keep-alive ping logic if the service has watchdog support enabled.
If you use this option, you must set NotifyAccess = (#notifyaccess) to open access to the notification socket provided by systemd.
If NotifyAccess = is not set, it is implicitly set to main.
The default is 0, which disables this feature.
The service can see if the service manager expects watchdog keepalive notifications.
See sd_watchdog_enabled (3) for more information.
You can use sd_event_set_watchdog (3) to enable automatic watchdog notification support.
Restart=
Configure whether the service process is terminated, killed, or restarted when the timeout is reached.
The service process can be the main service process, but [ExecStartPre =](# execstartpre-execstartpost), [ExecStartPost =](# execstartpre-execstartpost), ExecStop =, [ExecStopPost =](# It can also be one of the processes specified by execstoppost) or ExecReload =.
If the process stop is the result of a systemd operation (such as stopping or restarting the service), the service will not be restarted.
Timeouts include watchdog keep-alive ping missing expirations, service start, reload, and stop operations timeouts.
Take one of the following:
no (default) The service will not be restarted.
on-success It will only be restarted if the service process terminates successfully. In this context, successful termination is:
0 exit code
Either the signal SIGHUP, SIGINT, SIGTERM or SIGPIPE
Exit status and signal specified by SuccessExitStatus =
on-failure A watchdog timeout configured with a timeout was triggered when the process exited with a non-zero exit code and the operation ended with a signal (including a core dump, but excluding the four signals mentioned above) (eg reload). Sometimes the service is restarted.
on-abnormal The service is restarted when the process is terminated by a signal (including a core dump excluding the four signals above), when the operation times out, or when the watchdog timeout is triggered.
on-watchdog The service will only be restarted if the watchdog timeout for the service has expired (either terminated abnormally due to a signal or the timeout has been reached).
on-abort The service is restarted only if the service process terminates because an uncaught signal was not specified as a clean exit status.
always The service will be restarted regardless of whether it ended successfully.
** Table 2. Causes of termination and the impact of the `` Restart sequentially setting on them **
| Restart settings/Cause of termination | no | always | on-success | on-failure | on-abnormal | on-abort | on-watchdog |
|---|---|---|---|---|---|---|---|
| Clean exit code or signal | X | X | |||||
| Unclean exit code | X | X | |||||
| Unclean signal | X | X | X | X | |||
| Timeout | X | X | X | ||||
| Watchdog | X | X | X | X |
As an exception to the above settings, if an exit code or signal is specified in RestartPreventExitStatus =, or if the service is stopped by systemctl stop or an equivalent operation, the service will restart. It will not start.
Also, if an exit code or signal is specified in RestartForceExitStatus =, the service will always be restarted.
Note that restarting the service is affected by the unit start rate limit, which consists of StartLimitIntervalSec opens and StartLimitBurst represents.
See systemd.unit (5) for more information.
The restarted service will only fail after the start limit has been reached.
Setting this to ʻon-failure`` is the recommended choice for long-running services in order to attempt automatic recovery from errors and improve reliability. For services that can be terminated (and not restarted immediately) at your own option, you can substitute ʻon-abnormal``.
SuccessExitStatus=
Exit status considered successful, in addition to the normal termination code 0 and signals SIGHUP, SIGINT, SIGTERM, SIGPIPE when returned from the main service process. Gets a list of definitions.
The exit status definition is either a space-separated numeric exit code or an exit signal name.
Description example
SuccessExitStatus = 1 2 8 SIGKILL
In this example, the exit code 1, 2, 8 and the exit signal SIGKILL are considered to be the end of clean service.
This option may appear multiple times. In that case, the list of successful exit statuses is merged. If an empty string is assigned to this option, the list will be reset and all assignments prior to the empty string will be invalidated.
RestartPreventExitStatus= Gets a list of exit status definitions that prevent the service from automatically restarting, regardless of the restart setting configured with Restart =](#restart) when returned from the main service process. The exit status definition is either a numeric exit code or an exit signal name, separated by spaces. The default list is empty, so exit status is not excluded from the configured restart logic.
Description example
RestartPreventExitStatus = 1 6 SIGABRT
In this example, the exit codes 1 and 6 and the exit signal SIGABRT do not automatically restart the service.
This option may appear multiple times.
In that case, the list of restart prevention statuses will be merged.
If an empty string is assigned to this option, the list will be reset and all assignments prior to the empty string will be invalidated.
RestartForceExitStatus= Gets a list of exit status definitions that force an automatic restart of the service, regardless of the restart setting configured with Restart =](#restart) when returned from the main service process. The format of the argument is similar to RestartPreventExitStatus =.
RootDirectoryStartOnly=
Takes a Boolean argument.
For true The root directory configured with RootDirectory = option (see systemd.exec (5) for details) is only for processes started with ExecStart =. Applicable to other ExecStartPre =, ExecStartPost =, ExecReload =, ExecStop =, [ExecStopPost =]( It does not apply to the command #execstoppost).
If false, the setting will be applied to all configured commands in the same way.
The default is false.
NonBlocking=
Set the O_NONBLOCK flag on all file descriptors passed through socket-based activation.
If true, all file descriptors> = 3 (ie stdin, ) except those passed via file descriptor storage logic (see [FileDescriptorStoreMax =](#filedescriptorstoremax) for details). stdout, except stderr``) is in non-blocking mode because the O_NONBLOCK flag is set.
This option is only useful when combined with a socket unit, as described in systemd.socket (5), and does not affect file descriptors previously stored, such as in the file descriptor store.
The default is false.
NotifyAccess= Controls access to the service status notification socket so that it can be accessed with the sd_notify (3) call. Take one of the following:
none (default) Daemon status updates from service processes are not accepted and all status update messages are ignored.
main Only service updates sent from the service main process are accepted.
exec Only service updates sent by either the main process or the control process originating from one of the `ʻExec * = commands`` are accepted.
all All service updates from all members of the service control group are accepted.
This option must be set to open access to the notification socket when using Type = notify or WatchdogSec = (see above).
If these options are used but NotifyAccess = (#notifyaccess) is not configured, it is implicitly set to main.
Note that the sd_notify () notification is correctly associated with the unit only if the sending process still exists when PID 1 processes the message, or if the sending process is explicitly run-time tracked by the service manager. please.
The latter is the case when the service manager first branches the process, that is, all processes that match main or exec.
Conversely, if the unit's auxiliary process sends an sd_notify () message and exits immediately, the service manager will not be able to properly associate the message with the unit even if NotifyAccess = all is set. Ignore the message.
Sockets= Specifies the name of the socket unit that inherits the socket file descriptor when the service starts. Normally, you do not need to use this setting. All socket file descriptors (with different unit name extensions) that the unit shares the same name as the service are passed to the spawned process.
Note that the same socket file descriptor may be passed to multiple processes at the same time.
Also note that incoming socket traffic may eventually activate a different service than the one that is configured to inherit the socket file descriptor.
In other words, the Service appropriately setting of the .socketunit does not have to match the opposite of the [Sockets =](#sockets) setting of the .service`` it references.
This option may appear multiple times. In that case, the list of socket units will be merged. If an empty string is assigned to this option, the list of sockets will be reset and the settings specified before the empty string will have no effect.
FileDescriptorStoreMax=
Use the FDSTORE = 1 message in sd_pid_notify_with_fds (3) to configure the number of file descriptors that can be stored in the service manager of the service.
This helps implement a service that can be restarted without losing state after an explicit request or crash.
Open sockets and other file descriptors that should not be closed during a reboot can be saved this way.
The application state can be serialized to a file in / run or saved in the memfd_create (2) memory file descriptor.
The default is 0.
That is, you cannot save a file descriptor in a service descriptor.
All file descriptors passed from a particular service to the service manager are returned to the service's main process the next time the service is restarted.
The file descriptor passed to the service manager is when POLLHUP or POLLERR is displayed, or the service is completely stopped and the job is not queued or running. When it closes automatically.
If you want to use this option, you must set NotifyAccess = (#notifyaccess) to open access to the notification socket provided by systemd.
If NotifyAccess = is not set, it is implicitly set to main.
USBFunctionDescriptors=
Set the location of the file that contains the USB FunctionFS (https://www.kernel.org/doc/Documentation/usb/functionfs.txt) descriptor to implement the USB gadget feature.
This is only used in combination with socket units that have ListenUSBFunction properly set. The contents of this file are written to the `ʻep0 file after it is opened.
USBFunctionStrings= USB FunctionFS Configures the location of files that contain strings. The behavior is similar to USBFunctionDescriptors = above.
Check systemd.exec (5) and systemd.kill (5) for other settings.
This section describes the following optional command line parsing and variable and specifier replacement.
You can concatenate multiple command lines into a single directive by separating them with semicolons (these semicolons must be passed as separate words).
A single semicolon can be escaped as \;.
Each command line is separated by whitespace.
The first item is the command to execute and the second items are the arguments.
Double quotes ("...") and single quotes ('...' ) can be used to wrap the entire item.
(Starting quotes can only be displayed before or after a blank that is not enclosed in quotes, and ending quotes are followed by a blank or line ending)
In this case, everything up to the next matching quote is part of the same argument, and the quote itself is removed.
C-style escaping is also supported.
The following table lists the known escape patterns.
Only escape patterns that match the syntax of the table are allowed.
Other patterns may be added in the future, and unknown patterns are a warning.
In particular, the backslash must be doubled.
You can use a backslash (\) at the end of a line to merge lines.
This syntax is influenced by the shell syntax, but only the metacharacters and expansions described below are interpreted, and the variable expansion is different.
Specifically, redirect using <, <<, > , >>, pipe using |, & Running the program in the background you used, and other elements of the shell syntax are not supported.
The command you run may contain spaces, but you cannot use control characters.
The command line accepts the % specifier, as described in systemd.unit (5).
Basic environment variable substitution is supported.
If you use $ {FOO} on the command line as part of a word or as a single word
$ {FOO} is replaced with the value of the environment variable (including whitespace), replaced with the value of the environment variable separated by whitespace, zero or more arguments are generated, and converted to a single argument. Will be done.
If you use $ FOO as another word on the command line
Quotation marks take precedence when splitting into words and then removed.
If the command is not a full (absolute) path, it will be resolved to a full path using a fixed search path determined at compile time.
The directories searched are / usr / bin / and / usr / local / bin /, / usr / bin / on systems that use the / bin / directory. , / bin / and the corresponding sbin / for systems that use bin /, sbin /.
Therefore, it is safe to use only the executable name for an executable file that is in one of the "standard" directories, and you must use the absolute path if it is not in the standard directory.
It is recommended to use absolute paths to avoid ambiguity.
Tip: You can query this search path using systemd-path search-binaries-default.
Description example
Environment="ONE=one" 'TWO=two two'
ExecStart=echo $ONE $TWO ${TWO}
In this example, / bin / echo is executed with 4 arguments.
Description example
Environment=ONE='one' "TWO='two two' too" THREE=
ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
ExecStart=/bin/echo $ONE $TWO $THREE
This causes / bin / echo to be called twice, first with the arguments 'one', 'two two' too, "".
The second time it is called with the arguments ```one, two two, too``.
Use $$ to pass the literal dollar sign.
Variables whose value is unknown when expanded are treated as an empty string.
Note that the first argument (that is, the program you run) may not be a variable.
Variables used in this way can be defined by ʻEnvironment appropriately and ʻEnvironmentFile separately.
You can also use variables that are considered "static configuration" listed in the "Environment Variables for Generated Processes" section of systemd.exec (5) (which includes $ USER. Does not include $ TERM).
Please note that shell command line is not directly supported. If you use the shell command line, you must explicitly pass it to some shell implementation.
Description example
ExecStart=sh -c 'dmesg | tac'
Description example
ExecStart=echo one ; echo "two two"
This causes echo to run twice, each with one argument, `ʻoneand two two, respectively. You must use Type = oneshot`` because two commands are specified.
Description example
ExecStart=echo / >/dev/null & \; \
ls
In this example, echo is executed with 5 arguments.
/>/dev/null&;ls** Table 3. C escapes supported on command lines and environment variables **
| literal | Actual value |
|---|---|
\a |
bell |
\b |
backspace |
\f |
form feed |
\n |
newline |
\r |
carriage return |
\t |
tab |
\v |
vertical tab |
\\ |
backslash |
\" |
double quotes |
\' |
Quotation marks |
\s |
space |
\xxx |
Hexadecimal encoded character number xx |
\nnn |
Octal encoding character number nnn |
Type = simpleThe following unit file creates a service that runs / usr / sbin / foo-daemon.
The default Type = simple is assumed because Type = is not specified.
systemd expects the unit to start immediately after the program starts executing.
[Unit]
Description=Foo
[Service]
ExecStart=/usr/sbin/foo-daemon
[Install]
WantedBy=multi-user.target
Note that in this example systemd assumes that the process started by systemd will continue to exist until the end of service.
If your program daemonizes itself (forks, etc.), use Type = forking instead.
Since ExecStop = is not specified, systemd will send SIGTERM to all processes started from this service and will send SIGKILL even after the timeout.
This behavior can be changed.
See systemd.kill (5) for more information.
This unit type does not include notification when the service initialization is complete.
Type = notify if the service understands the systemd notification protocol, Type = forking if the service can handle itself in the background, and the unit will give the DBus name after initialization is complete. You must use another unit type, such as Type = dbus, to get it.
Please refer to the following.
Type = oneshotUnits may need to take actions without maintaining an active process, such as file system checks and startup cleanup actions.
Type = oneshot exists for such cases.
This type of unit waits for the specified process to terminate before falling back inactive.
The following units perform cleanup actions:
[Unit]
Description=Cleanup old Foo data
[Service]
Type=oneshot
ExecStart=/usr/sbin/foo-cleanup
[Install]
WantedBy=multi-user.target
systemd considers the unit to be in the starting state until the end of the program.
Therefore, ordered dependencies start after the program finishes.
The unit will return to the ʻinactive`` state when execution is complete and will never be in the ʻactive`` state.
That is, another request to start the unit will perform the action again.
Type = oneshot is the only service unit that may have multiple ExecStart = specified.
They run in sequence until all succeed or one fails.
Like the oneshot service, some units need to run a program to configure something and then run another program to shut down, but the process is active while it is considered started. It remains.
Network configurations may fall into this category.
Another use case is when the oneshot service is not executed when it is called as a dependency, but is executed for the first time.
Therefore systemd knows the setting RemainAfterExit = yes.
This causes systemd to assume that the unit is active if the start action completes successfully.
This directive can be used with all types, but is most useful with Type = oneshot and Type = simple.
If Type = oneshot, systemd waits for the start action to complete before considering the unit to be active, so the dependency will only start after the start action is successful.
If Type = simple, the dependency will start immediately after the start action is dispatched.
The following is an example of a simple static firewall.
[Unit]
Description=Simple firewall
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/simple-firewall-start
ExecStop=/usr/local/sbin/simple-firewall-stop
[Install]
WantedBy=multi-user.target
After the start action is finished, the unit is considered running, so calling systemctl start again on that unit will not take any action.
Many traditional daemon / service backgrounds (that is, fork, daemonize) put themselves in the background at startup.
To support this mode of operation, set Type = forking in the service's unit file.
systemd considers the service to be in the process of initialization while the original program is still running.
The service is considered started if it exits successfully and at least the process remains (or RemainAfterExit = no).
Traditional daemons often consist of only one process.
Therefore, if only one process remains after the original process terminates, systemd considers that process to be the main process for the service.
In that case, the $ MAINPID variable can be used with ExecReload =, ExecStop =, and so on.
If more than one process remains, systemd cannot determine the main process and does not assume it is.
In that case, $ MAINPID will not be expanded.
However, if the process decides to write a traditional PID file, systemd can read the main PID from it.
Set PIDFile = as appropriate.
Note that the daemon must write the PID file before it completes the initialization.
Otherwise, systemd may try to read the PID file before it is generated.
The following example shows a simple daemon that branches and starts a process in the background:
[Unit]
Description=Some simple daemon
[Service]
Type=forking
ExecStart=/usr/sbin/my-simple-daemon -d
[Install]
WantedBy=multi-user.target
See systemd.kill (5) for more information on how systemd affects how it terminates its service.
For services that get their name on the DBus system bus, use Type = dbus and set the corresponding BusName =.
Services should not be forked (daemonized).
systemd considers the service initialized when it gets its name on the system bus.
The following example shows a typical DBus service.
[Unit]
Description=Simple DBus service
[Service]
Type=dbus
BusName=org.example.simple-dbus-service
ExecStart=/usr/sbin/simple-dbus-service
[Install]
WantedBy=multi-user.target
For services that can be activated on the bus, do not include the [Install] section in the systemd service file.
Use the `` SystemdService appropriately option in the corresponding DBus service file instead.
For example (/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service):
[D-BUS Service]
Name=org.example.simple-dbus-service
Exec=/usr/sbin/simple-dbus-service
User=root
SystemdService=simple-dbus-service.service
See systemd.kill (5) for more information on how systemd affects how it terminates its service.
Services with Type = simple are very easy to write, but they have the major drawback of not being able to notify systemd that the initialization of a particular service is complete.
For this reason, systemd supports a simple notification protocol that allows the daemon to let systemd know that initialization is complete.
Use Type = notify for this.
A typical service file for such a daemon looks like this:
[Unit]
Description=Simple notifying service
[Service]
Type=notify
ExecStart=/usr/sbin/simple-notifying-service
[Install]
WantedBy=multi-user.target
Note that the daemon must support systemd's notification protocol.
Otherwise systemd considers the service not yet started and kills it after a timeout.
See sd_notify (3) for information on how to update the daemon to transparently support this protocol.
systemd considers the unit to be in the starting state until a ready notification arrives.
See systemd.kill (5) for more information on how systemd affects how it terminates its service.
SEE ALSO
NOTES
Recommended Posts