view release on metacpan or  search on metacpan

lib/Config/Model/models/Systemd/Section/Service.pl  view on Meta::CPAN

Defaults to the setting C<DefaultOOMPolicy> in
L<systemd-system.conf(5)>
is set to, except for units where C<Delegate> is turned on, where it defaults to
C<continue>.

Use the C<OOMScoreAdjust> setting to configure whether processes of the unit
shall be considered preferred or less preferred candidates for process termination by the Linux OOM
killer logic. See
L<systemd.exec(5)> for
details.

This setting also applies to
L<systemd-oomd.service(8)>.
Similarly to the kernel OOM kills performed by the kernel, this setting determines the state of the
unit after systemd-oomd kills a cgroup associated with it.',
      'OpenFile' => 'Takes an argument of the form C<path:fd-name:options>,
where:
C<path> is a path to a file or an C<AF_UNIX> socket in the file system;C<fd-name> is a name that will be associated
with the file descriptor;
the name may contain any ASCII character, but must exclude control characters and ":", and must be at most 255
characters in length;
it is optional and, if not provided, defaults to the file name;C<options> is a comma-separated list of access options;
possible values are
C<read-only>,
C<append>,
C<truncate>,
C<graceful>;
if not specified, files will be opened in C<rw> mode;
if C<graceful> is specified, errors during file/socket opening are ignored.
Specifying the same option several times is treated as an error.
The file or socket is opened by the service manager and the file descriptor is passed to the service.
If the path is a socket, we call connect() on it.
See L<sd_listen_fds(3)>
for more details on how to retrieve these file descriptors.

This setting is useful to allow services to access files/sockets that they cannot access themselves
(due to running in a separate mount namespace, not having privileges, ...).

This setting can be specified multiple times, in which case all the specified paths are opened and the file descriptors
passed to the service.
If the empty string is assigned, the entire list of open files defined prior to this is reset.',
      'PIDFile' => 'Takes a path referring to the PID file of the service. Usage of this option is
recommended for services where C<Type> is set to C<forking>. The path
specified typically points to a file below C</run/>. If a relative path is
specified for system service, then it is hence prefixed with C</run/>, and prefixed
with C<$XDG_RUNTIME_DIR> if specified in a user service. The service manager will
read the PID of the main process of the service from this file after start-up of the service. The
service manager will not write to the file configured here, although it will remove the file after
the service has shut down if it still exists. The PID file does not need to be owned by a privileged
user, but if it is owned by an unprivileged user additional safety restrictions are enforced: the
file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and
the PID file must refer to a process already belonging to the service.

Note that PID files should be avoided in modern projects. Use C<Type=notify>,
C<Type=notify-reload> or C<Type=simple> where possible, which does not
require use of PID files to determine the main process of a service and avoids needless
forking.',
      'RefreshOnReload' => 'Takes a boolean argument, or a list of resources defined in
L<systemd.exec(5)>.
Possible values are C<extensions> and C<credentials>, separated by space.
Prepending the list with a single tilde character (C<~>) inverts the effect.
Defaults to C<extensions>. An empty assignment resets the list to default. If enabled,
the corresponding resources (C<ExtensionImages>/C<ExtensionDirectories>
for C<extensions> and C<LoadCredential>/C<ImportCredential>/
C<SetCredential> (along with their C<Encrypted> counterparts)
for C<credentials>) will be refreshed on service reload. If C<yes>,
all resources listed above that are used by the service shall be refreshed.

Specially, if this option is set explicitly, and the respective resources are in use,
the service may be reloaded without any actual reload mechanism (C<ExecReload>
or C<Type=notify-reload>) for notifying the main process, in which case the reload
is considered complete immediately after refreshing.',
      'ReloadSignal' => 'Configures the UNIX process signal to send to the service\'s main process when asked
to reload the service\'s configuration. Defaults to C<SIGHUP>. This option has no
effect unless C<Type>=C<notify-reload> is used, see
above.',
      'RemainAfterExit' => 'Takes a boolean value that specifies whether
the service shall be considered active even when all its
processes exited. Defaults to C<no>.',
      'Restart' => 'Configures whether the service shall be restarted when the service process exits,
is killed, or a timeout is reached. The service process may be the main service process, but it may
also be one of the processes specified with C<ExecStartPre>,
C<ExecStartPost>, C<ExecStop>, C<ExecStopPost>,
or C<ExecReload>. When the death of the process is a result of systemd operation
(e.g. service stop or restart), the service will not be restarted. Timeouts include missing the watchdog
"keep-alive ping" deadline and a service start, reload, and stop operation timeouts.

Takes one of C<no>, C<on-success>, C<on-failure>,
C<on-abnormal>, C<on-watchdog>, C<on-abort>, or
C<always>. If set to C<no> (the default), the service will not be restarted.
If set to C<on-success>, it will be restarted only when the service process exits cleanly.
In this context, a clean exit means any of the following:
exit code of 0;for types other than C<Type=oneshot>, one of the signals
C<SIGHUP>, C<SIGINT>,
C<SIGTERM>, or C<SIGPIPE>;
exit statuses and signals specified in
C<SuccessExitStatus>.
If set to C<on-failure>, the service will be restarted when the process exits with
a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementioned
four signals), when an operation (such as service reload) times out, and when the configured watchdog
timeout is triggered. If set to C<on-abnormal>, the service will be restarted when
the process is terminated by a signal (including on core dump, excluding the aforementioned four signals),
when an operation times out, or when the watchdog timeout is triggered. If set to C<on-abort>,
the service will be restarted only if the service process exits due to an uncaught signal not specified
as a clean exit status. If set to C<on-watchdog>, the service will be restarted
only if the watchdog timeout for the service expires. If set to C<always>, the service
will be restarted regardless of whether it exited cleanly or not, got terminated abnormally by
a signal, or hit a timeout. Note that C<Type=oneshot> services will never be restarted
on a clean exit status, i.e. C<always> and C<on-success> are rejected
for them.

As exceptions to the setting above, the service will not
be restarted if the exit code or signal is specified in
C<RestartPreventExitStatus> (see below) or
the service is stopped with systemctl stop
or an equivalent operation. Also, the services will always be
restarted if the exit code or signal is specified in
C<RestartForceExitStatus> (see below).

Note that service restart is subject to unit start rate
limiting configured with C<StartLimitIntervalSec>
and C<StartLimitBurst>, see
L<systemd.unit(5)>
for details.

Setting this to C<on-failure> is the