view release on metacpan or  search on metacpan

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

It is recommended to use this setting for commands that communicate with the service requesting
clean termination. For post-mortem clean-up steps use C<ExecStopPost> instead.
',
        'type' => 'list'
      },
      'ExecStopPost',
      {
        'cargo' => {
          'type' => 'leaf',
          'value_type' => 'uniline'
        },
        'description' => "Additional commands that are executed after the service is stopped. This includes cases where
the commands configured in C<ExecStop> were used, where the service does not have any
C<ExecStop> defined, or where the service exited unexpectedly. This argument takes multiple
command lines, following the same scheme as described for C<ExecStart>. Use of these settings
is optional. Specifier and environment variable substitution is supported. Note that \x{2013} unlike
C<ExecStop> \x{2013} commands specified with this setting are invoked when a service failed to start
up correctly and is shut down again.

It is recommended to use this setting for clean-up operations that shall be executed even when
the service failed to start up correctly. Commands configured with this setting need to be able to
operate even if the service failed starting up half-way and left incompletely initialized data
around. As the service's processes have likely exited already when the commands specified with this
setting are executed they should not attempt to communicate with them.

Note that all commands that are configured with this setting are invoked with the result code of the
service, as well as the main process' exit code and status, set in the C<\$SERVICE_RESULT>,
C<\$EXIT_CODE> and C<\$EXIT_STATUS> environment variables, see
L<systemd.exec(5)> for
details.

Note that the execution of C<ExecStopPost> is taken into account for the purpose of
C<Before>/C<After> ordering constraints.",
        'type' => 'list'
      },
      'RestartSec',
      {
        'description' => 'Configures the time to sleep before restarting
a service (as configured with C<Restart>).
Takes a unit-less value in seconds, or a time span value such
as "5min 20s". Defaults to 100ms.',
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'RestartSteps',
      {
        'description' => 'Configures the number of exponential steps to take to increase the interval
of auto-restarts from C<RestartSec> to C<RestartMaxDelaySec>.
Takes a positive integer or 0 to disable it. Defaults to 0. Hint: values
between 3 and 5 are good choices when exponential backoff is desired.

Example:

    RestartSec=10s
    RestartSteps=4
    RestartMaxDelaySec=160s

This will produce the following restart intervals: 10s, 20s, 40s, 80s, 160s, 160s, 160s, etc.
Notice the geometric interpolation and the resulting constant ratio between intervals; here it is 2.
The formula for the ratio is

(C<RestartMaxDelaySec> / C<RestartSec>)^(1 / C<RestartSteps>)
. A (repeating) delay equal to C<RestartMaxDelaySec> is always
reached after
C<RestartSteps> + 1
 steps.

This setting is effective only if C<RestartMaxDelaySec> is also set and
C<RestartSec> is not zero.',
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'RestartMaxDelaySec',
      {
        'description' => 'Configures the longest time to sleep before restarting a service
as the interval goes up with C<RestartSteps>. Takes a value
in the same format as C<RestartSec>, or C<infinity>
to disable the setting. Defaults to C<infinity>.

This setting is effective only if C<RestartSteps> is also set and
C<RestartSec> is not zero.',
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'TimeoutStartSec',
      {
        'description' => "Configures the time to wait for start-up. If a daemon service does not signal
start-up completion within the configured time, the service will be considered failed and will be
shut down again. The precise action depends on the C<TimeoutStartFailureMode>
option. Takes a unit-less value in seconds, or a time span value such as \"5min 20s\". Pass
C<infinity> to disable the timeout logic. Defaults to
C<DefaultTimeoutStartSec> set in the manager, except when
C<Type=oneshot> is used, in which case the timeout is disabled by default (see
L<systemd-system.conf(5)>).

If a service of C<Type=notify>/C<Type=notify-reload> sends
C<EXTEND_TIMEOUT_USEC=\x{2026}>, this may cause the start time to be extended beyond
C<TimeoutStartSec>. The first receipt of this message must occur before
C<TimeoutStartSec> is exceeded, and once the start time has extended beyond
C<TimeoutStartSec>, the service manager will allow the service to continue to start,
provided the service repeats C<EXTEND_TIMEOUT_USEC=\x{2026}> within the interval specified
until the service startup status is finished by C<READY=1>. (see
L<sd_notify(3)>).

Note that the start timeout is also applied to service reloads, regardless of whether implemented
through C<ExecReload> or via the reload logic enabled via C<Type=notify-reload>.
If the reload does not complete within the configured time, the reload will be considered failed and
the service will continue running with the old configuration. This will not affect the running service,
but will be logged and will cause e.g. systemctl reload to fail.",
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'TimeoutStopSec',
      {
        'description' => "This option serves two purposes. First, it configures the time to wait for each
C<ExecStop> command. If any of them times out, subsequent C<ExecStop> commands
are skipped and the service will be terminated by C<SIGTERM>. If no C<ExecStop>
commands are specified, the service gets the C<SIGTERM> immediately. This default behavior
can be changed by the C<TimeoutStopFailureMode> option. Second, it configures the time
to wait for the service itself to stop. If it does not terminate in the specified time, it will be forcibly terminated