view release on metacpan or  search on metacpan

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

        'choice' => [
          'abort',
          'kill',
          'terminate'
        ],
        'description' => '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.
',
        'type' => 'leaf',
        'value_type' => 'enum'
      },
      'RuntimeMaxSec',
      {
        'description' => "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=\x{2026}>, 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=\x{2026}> within the interval specified
until the service shutdown is achieved by C<STOPPING=1> (or termination). (see
L<sd_notify(3)>).
",
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'RuntimeRandomizedExtraSec',
      {
        'description' => '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.
',
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'WatchdogSec',
      {
        'description' => '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.
',
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'Restart',
      {
        'choice' => [
          'always',
          'no',
          'on-abnormal',
          'on-abort',
          'on-failure',
          'on-success',
          'on-watchdog'
        ],
        'description' => '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.',
        'type' => 'leaf',
        'value_type' => 'enum'
      },
      'RestartMode',
      {
        'description' => '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