Unit Section⌗

The Unit section is used to define the startup order and dependencies of units.

Description⌗

A brief introduction to the unit name. This option should be concise and easy to understand.

Example⌗

Description=Nginx Web Server

Documentation⌗

A list of documentation URLs for the unit, with multiple URLs separated by spaces. Supports URL types such as https://, file:, info:, and man:.

Example⌗

Documentation=http://nginx.org/en/docs file:/usr/local/nginx/docs

Requires⌗

Defines strong dependencies for the unit, specifying a list of other units that the current unit depends on, separated by spaces. If this unit is activated, the units listed here will also be activated. If one of these units cannot be activated and After is set, the current unit will fail to activate (this involves dependency relationships, not startup order; by default, they start in parallel).

Wants⌗

Defines weak dependencies for the unit. These are other units that work with the current unit, but if they are not running, the current unit will not fail to start (this involves dependency relationships, not startup order; by default, they start in parallel).

BindsTo⌗

Similar to Requires, it specifies that if the units it specifies exit, it will cause the current unit to stop running.

Before⌗

If the units specified in this field are also to be started, they must be started after the current unit (only involves startup order, not dependency relationships).

After⌗

If the units specified in this field are also to be started, they must be started before the current unit (only involves startup order, not dependency relationships).

Conflicts⌗

The units specified here cannot run at the same time as the current unit.

Condition…⌗

Conditions that must be met for the current unit to run, otherwise it will not run.

Assert…⌗

Conditions that must be met for the current unit to run, otherwise it will report a startup failure.

  • Requisite:
  • Wants: Specifies dependent services; not strongly dependent, if After is not specified, this unit and the dependent unit will not start in parallel.
  • BindsTo:
  • After: Specifies dependent services, starts this service after the specified services start.
  • PartOf:
  • Conflicts:
  • OnFailure:
  • PropagatesReloadTo:
  • ReloadPropagatedFrom:
  • JoinsNamespaceOf:
  • RequiresMountsFor:
  • OnFailureJobMode:
  • IgnoreOnIsolate:
  • StopWhenUnneeded:
  • RefuseManualStart:
  • RefuseManualStop:
  • AllowIsolate:
  • DefaultDependencies:
  • CollectMode:
  • FailureAction:
  • SuccessAction:
  • FailureActionExitStatus:
  • SuccessActionExitStatus:
  • JobTimeoutSec:
  • JobRunningTimeoutSec:
  • JobTimeoutAction:
  • JobTimeoutRebootArgument:
  • StartLimitIntervalSec:
  • StartLimitBurst:
  • StartLimitAction:
  • RebootArgument:

Dependency relationships are typically used on services rather than targets. For example, network.target is generally introduced by a service that configures network interfaces, so placing your custom unit after that service is sufficient, as network.target has already started.

Service Section⌗

This section defines the startup behavior of the Unit.

Options in this section can use a hyphen - to indicate error suppression, meaning that when an error occurs, it does not affect the execution of other commands.

Type⌗

Defines the startup type of the Unit.

Options⌗

  • simple (default): Systemd considers that the service will start immediately. The service process does not fork. If the service needs to start other services, do not use this type to start, unless the service is socket-activated.
  • forking: Systemd considers the service to have started successfully when the service process forks and the parent process exits. For regular daemons, use this startup type unless you are certain it cannot meet your needs. When using this startup type, you should also specify PIDFile= so that Systemd can track the main process of the service.
  • oneshot: This option is suitable for services that only perform one task and then exit immediately. You may need to set RemainAfterExit=yes so that Systemd still considers the service to be active after the service process exits.
  • notify: Same as simple, but the service is expected to send a signal to Systemd when it’s ready. This notification is implemented by libsystemd-daemon.so.
  • dbus: If started this way, Systemd considers the service ready when the specified BusName appears on the DBus system bus.
  • idle: Systemd will wait for all tasks to be processed before starting to execute units of the idle type. Other behaviors are similar to Type=simple.

User⌗

Group⌗

DynamicUser⌗

SupplementaryGroups⌗

PAMName⌗

WorkingDirectory⌗

Defines the working directory when running the service. If this field is not set, it checks whether the User field is set. If neither is set, the default value for this field is /. If the User value is set, this field is the ~ directory of the specified user, i.e., the Home directory.

Example⌗

WorkingDirectory=~

Scope⌗

  • service.service;
  • socket.socket;
  • mount.mount;
  • swap.swap.

LimitCPU⌗

LimitFSIZE⌗

LimitDATA⌗

LimitSTACK⌗

LimitCORE⌗

LimitRSS⌗

LimitNOFILE⌗

LimitAS⌗

LimitNPROC⌗

LimitMEMLOCK⌗

LimitLOCKS⌗

LimitSIGPENDING⌗

LimitMSGQUEUE⌗

LimitNICE⌗

LimitRTPRIO⌗

LimitRTTIME⌗

LimitCPU⌗

LimitCPU⌗

LimitCPU⌗

LimitCPU⌗

LimitCPU⌗

LimitCPU⌗

LimitCPU⌗

LimitCPU⌗

BindPaths⌗

RemainAfterExit⌗

GuessMainPID⌗

PIDFile⌗

BusName⌗

ExecStart⌗

The command to start the current service. Can be combined with the EnvironmentFile configuration item to use $OPTIONS to get KEY/VALUE from the configuration file.

/usr/sbin/sshd -D $OPTIONS

ExecStartPre⌗

Commands to execute before starting the current service.

ExecStartPost⌗

Commands to execute after starting the current service.

ExecReload⌗

Commands to execute when restarting the current service.

ExecStop⌗

Commands to execute when stopping the current service.

ExecStopPost⌗

Commands to execute after stopping the current service.

RestartSec⌗

The number of seconds to wait before automatically restarting the current service.

TimeoutStartSec⌗

TimeoutStopSec⌗

TimeoutSec⌗

Defines the number of seconds Systemd will wait before stopping the current service.

RuntimeMaxSec⌗

WatchdogSec⌗

Restart⌗

Defines under what circumstances Systemd will automatically restart the current service.

Options⌗

  • no (default): Will not restart after exit.
  • on-success: Will only restart on normal exit (exit status code 0).
  • on-failure: Will restart on abnormal exit (non-zero exit status code), including termination by signals and timeouts.
  • on-abnormal: Will only restart when terminated by signals or timeouts.
  • on-abort: Will only restart when terminated by uncaught signals.
  • on-watchdog: Will restart on timeout exit.
  • always: Will always restart regardless of the exit reason.

Environment⌗

Specifies environment variables.

EnvironmentFile⌗

Many software applications have their own environment parameter files, which can be read using the EnvironmentFile field. The key=value pairs inside the file can be accessed in the current configuration file using the $key format.

KillMode⌗

Defines how Systemd stops the Unit.

Options⌗

  • control-group (default): All child processes in the current control group will be killed.
  • process: Indicates that only the main process will be stopped, not the child processes. This configuration is rarely used, but is used in SSH. If you need to stop the sshd service but don’t want the current ssh session to disconnect.
  • mixed: The main process will receive a SIGTERM signal, and child processes will receive a SIGKILL signal.
  • none: No processes will be killed, only the service’s stop command will be executed.

SuccessExitStatus⌗

RestartPreventExitStatus⌗

RestartForceExitStatus⌗

RootDirectoryStartOnly⌗

NonBlocking⌗

NotifyAccess⌗

Sockets⌗

FileDescriptorStoreMax⌗

USBFunctionDescriptors⌗

USBFunctionStrings⌗

PermissionsStartOnly⌗

Whether to execute *Pre and *Post scripts with root user permissions, such as ExecStartPre, ExecStartPost.

Note: This field has been deprecated but not removed.

Example⌗

PermissionsStartOnly=true

Install Section⌗

Usually the last block of the configuration file, used to define how to start and whether to start at boot.

WantedBy⌗

Its value is one or more Targets. When the current Unit is activated (enabled), symbolic links will be placed in subdirectories under /etc/systemd/system formed by the Target name + .wants suffix.

Example⌗

WantedBy=multi-user.target

RequiredBy⌗

Its value is one or more Targets. When the current Unit is activated, symbolic links will be placed in subdirectories under /etc/systemd/system formed by the Target name + .required suffix.

Example⌗

WantedBy=multi-user.target

Alias⌗

Aliases that can be used to start the current Unit.

Example⌗

Alias=nginx

Also⌗

Other Units that will be activated simultaneously when the current Unit is activated (enabled).

Example⌗

Also=php-fpm.service

Socket Activation⌗

We know that having an HTTP server running consumes resources. So is it possible to only start the service when someone accesses it, and shut it down otherwise? This is called “Socket Activation” in Systemd. Developers can specify the port that the Socket listens on, and the system automatically starts or stops the service based on whether it receives requests. It’s not hard to imagine that by adding a load balancer in front, this is equivalent to implementing a simple cloud service that automatically scales up or down based on traffic volume.

I hope this is helpful, Happy hacking…