view release on metacpan or  search on metacpan

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

C<LoadCredential>. In order to embed binary data into the credential data use
C-style escaping (i.e. C<\n> to embed a newline, or C<\x00> to embed
a C<NUL> byte).

The C<SetCredentialEncrypted> setting is identical to
C<SetCredential> but expects an encrypted credential in literal form as value. This
allows embedding confidential credentials securely directly in unit files. Use
L<systemd-creds(1)>'
C<-p> switch to generate suitable C<SetCredentialEncrypted> lines
directly from plaintext credentials. For further details see
C<LoadCredentialEncrypted> above.

When multiple credentials of the same name are found, credentials found by
C<LoadCredential>, C<LoadCredentialEncrypted> and
C<ImportCredential> take priority over credentials found by
C<SetCredential>. As such, C<SetCredential> will act as default if
no credentials are found by any of the former. In this case, not being able to retrieve the credential
from the path specified in C<LoadCredential> or
C<LoadCredentialEncrypted> is not considered fatal. I< Optional. Type uniline.  > 

=head2 UtmpIdentifier

Takes a four character identifier string for an L<utmp(5)> and wtmp entry
for this service. This should only be set for services such as getty implementations (such
as L<agetty(8)>) where utmp/wtmp
entries must be created and cleared before and after execution, or for services that shall be executed as if
they were run by a getty process (see below). If the configured string is longer than four
characters, it is truncated and the terminal four characters are used. This setting interprets %I style string
replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this
service. I< Optional. Type uniline.  > 

=head2 UtmpMode

Takes one of C<init>, C<login> or C<user>. If
C<UtmpIdentifier> is set, controls which type of L<utmp(5)>/wtmp entries
for this service are generated. This setting has no effect unless C<UtmpIdentifier> is set
too. If C<init> is set, only an C<INIT_PROCESS> entry is generated and the
invoked process must implement a getty-compatible utmp/wtmp logic. If
C<login> is set, first an C<INIT_PROCESS> entry, followed by a
C<LOGIN_PROCESS> entry is generated. In this case, the invoked process must implement a
L<login(1)>-compatible
utmp/wtmp logic. If C<user> is set, first an C<INIT_PROCESS> entry, then a
C<LOGIN_PROCESS> entry and finally a C<USER_PROCESS> entry is
generated. In this case, the invoked process may be any process that is suitable to be run as session
leader. Defaults to C<init>. I< Optional. Type enum. choice: 'init', 'login', 'user'.  > 

=head2 KillMode

Specifies how processes of this unit shall be killed. One of
C<control-group>, C<mixed>, C<process>,
C<none>.

If set to C<control-group>, all remaining processes in the control group of this
unit will be killed on unit stop (for services: after the stop command is executed, as configured
with C<ExecStop>). If set to C<mixed>, the
C<SIGTERM> signal (see below) is sent to the main process while the subsequent
C<SIGKILL> signal (see below) is sent to all remaining processes of the unit's
control group. If set to C<process>, only the main process itself is killed (not
recommended!). If set to C<none>, no process is killed (strongly recommended
against!). In this case, only the stop command will be executed on unit stop, but no process will be
killed otherwise.  Processes remaining alive after stop are left in their control group and the
control group continues to exist after stop unless empty.

Note that it is not recommended to set C<KillMode> to
C<process> or even C<none>, as this allows processes to escape
the service manager's lifecycle and resource management, and to remain running even while their
service is considered stopped and is assumed to not consume any resources.

Processes will first be terminated via C<SIGTERM> (unless the signal to send
is changed via C<KillSignal> or C<RestartKillSignal>). Optionally,
this is immediately followed by a C<SIGHUP> (if enabled with
C<SendSIGHUP>). If processes still remain after:
the main process of a unit has exited (applies to C<KillMode>:
C<mixed>)the delay configured via the C<TimeoutStopSec> has passed
(applies to C<KillMode>: C<control-group>, C<mixed>,
C<process>)
the termination request is repeated with the C<SIGKILL> signal or the signal specified via
C<FinalKillSignal> (unless this is disabled via the C<SendSIGKILL>
option). See L<kill(2)>
for more information.

Defaults to C<control-group>. I< Optional. Type uniline.  > 

=head2 KillSignal

Specifies which signal to use when stopping a service. This controls the signal that
is sent as first step of shutting down a unit (see above), and is usually followed by
C<SIGKILL> (see above and below). For a list of valid signals, see
L<signal(7)>.
Defaults to C<SIGTERM>.

Note that, right after sending the signal specified in this setting, systemd will always send
C<SIGCONT>, to ensure that even suspended tasks can be terminated cleanly. I< Optional. Type uniline.  > 

=head2 RestartKillSignal

Specifies which signal to use when restarting a service. The same as
C<KillSignal> described above, with the exception that this setting is used in a
restart job. Not set by default, and the value of C<KillSignal> is used. I< Optional. Type uniline.  > 

=head2 SendSIGHUP

Specifies whether to send
C<SIGHUP> to remaining processes immediately
after sending the signal configured with
C<KillSignal>. This is useful to indicate to
shells and shell-like programs that their connection has been
severed. Takes a boolean value. Defaults to C<no>.
I< Optional. Type boolean.  > 

=over 4

=item upstream_default value :

no

=back



=head2 SendSIGKILL

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

service does not terminate the C<FinalKillSignal> is sent after
C<TimeoutStopSec>. If C<abort> is set, C<WatchdogSignal> is sent
instead and C<TimeoutAbortSec> applies before sending C<FinalKillSignal>.
This setting may be used to analyze services that fail to start-up or shut-down intermittently.
By using C<kill> the service is immediately terminated by sending
C<FinalKillSignal> without any further timeout. This setting can be used to expedite the
shutdown of failing services.
I< Optional. Type enum. choice: 'abort', 'kill', 'terminate'.  > 

=head2 TimeoutStopFailureMode

These options configure the action that is taken in case a daemon service does not signal
start-up within its configured C<TimeoutStartSec>, respectively if it does not stop within
C<TimeoutStopSec>. Takes one of C<terminate>, C<abort> and
C<kill>. Both options default to C<terminate>.

If C<terminate> is set the service will be gracefully terminated by sending the signal
specified in C<KillSignal> (defaults to C<SIGTERM>, see
L<systemd.kill(5)>). If the
service does not terminate the C<FinalKillSignal> is sent after
C<TimeoutStopSec>. If C<abort> is set, C<WatchdogSignal> is sent
instead and C<TimeoutAbortSec> applies before sending C<FinalKillSignal>.
This setting may be used to analyze services that fail to start-up or shut-down intermittently.
By using C<kill> the service is immediately terminated by sending
C<FinalKillSignal> without any further timeout. This setting can be used to expedite the
shutdown of failing services.
I< Optional. Type enum. choice: 'abort', 'kill', 'terminate'.  > 

=head2 RuntimeMaxSec

Configures a maximum time for the service to run. If this is used and the service has been
active for longer than the specified time it is terminated and put into a failure state. Note that this setting
does not have any effect on C<Type=oneshot> services, as they terminate immediately after
activation completed (use C<TimeoutStartSec> to limit their activation).
Pass C<infinity> (the default) to configure no runtime limit.

If a service of C<Type=notify>/C<Type=notify-reload> sends
C<EXTEND_TIMEOUT_USEC=…>, this may cause the runtime to be extended beyond
C<RuntimeMaxSec>. The first receipt of this message must occur before
C<RuntimeMaxSec> is exceeded, and once the runtime has extended beyond
C<RuntimeMaxSec>, the service manager will allow the service to continue to run,
provided the service repeats C<EXTEND_TIMEOUT_USEC=…> within the interval specified
until the service shutdown is achieved by C<STOPPING=1> (or termination). (see
L<sd_notify(3)>).
I< Optional. Type uniline.  > 

=head2 RuntimeRandomizedExtraSec

This option modifies C<RuntimeMaxSec> by increasing the maximum runtime by an
evenly distributed duration between 0 and the specified value (in seconds). If C<RuntimeMaxSec> is
unspecified, then this feature will be disabled.
I< Optional. Type uniline.  > 

=head2 WatchdogSec

Configures the watchdog timeout for a service.
The watchdog is activated when the start-up is completed. The
service must call
L<sd_notify(3)>
regularly with C<WATCHDOG=1> (i.e. the
"keep-alive ping"). If the time between two such calls is
larger than the configured time, then the service is placed in
a failed state and it will be terminated with
C<SIGABRT> (or the signal specified by
C<WatchdogSignal>). By setting
C<Restart> to C<on-failure>,
C<on-watchdog>, C<on-abnormal> or
C<always>, the service will be automatically
restarted. The time configured here will be passed to the
executed service process in the
C<WATCHDOG_USEC> environment variable. This
allows daemons to automatically enable the keep-alive pinging
logic if watchdog support is enabled for the service. If this
option is used, C<NotifyAccess> (see below)
should be set to open access to the notification socket
provided by systemd. If C<NotifyAccess> is
not set, it will be implicitly set to C<main>.
Defaults to 0, which disables this feature. The service can
check whether the service manager expects watchdog keep-alive
notifications. See
L<sd_watchdog_enabled(3)>
for details.
L<sd_event_set_watchdog(3)>
may be used to enable automatic watchdog notification support.
I< Optional. Type uniline.  > 

=head2 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
recommended choice for long-running services, in order to
increase reliability by attempting automatic recovery from
errors. For services that shall be able to terminate on their
own choice (and avoid immediate restarting),
C<on-abnormal> is an alternative choice. I< Optional. Type enum. choice: 'always', 'no', 'on-abnormal', 'on-abort', 'on-failure', 'on-success', 'on-watchdog'.  > 

=head2 RestartMode

Takes a string value that specifies how a service should restart:
If set to C<normal> (the default), the service restarts by going through
a failed/inactive state.If set to C<direct>, the service transitions to the activating
state directly during auto-restart, skipping failed/inactive state.
C<ExecStopPost> is still invoked.
C<OnSuccess> and C<OnFailure> are skipped.This option is useful in cases where a dependency can fail temporarily but we
do not
want these temporary failures to make the dependent units fail. Dependent units are not
notified of these temporary failures.If set to C<debug>, the service manager will log messages that are
related to this unit at debug level while automated restarts are attempted, until either the
service hits the rate limit or it succeeds, and the C<$DEBUG_INVOCATION=1>
environment variable will be set for the unit. This is useful to be able to get additional