Config-Model-Systemd

 view release on metacpan or  search on metacpan

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

C<null> connects standard output to C</dev/null>, i.e. everything written
to it will be lost.

C<tty> connects standard output to a tty (as configured via C<TTYPath>,
see below). If the TTY is used for output only, the executed process will not become the controlling process of
the terminal, and will not fail or wait for other processes to release the terminal. Note: if a unit
tries to print multiple lines to a TTY during bootup or shutdown, then there's a chance that those
lines will be broken up by status messages. SetShowStatus() can be used to
prevent this problem. See
L<org.freedesktop.systemd1(5)>
for details.

C<journal> connects standard output with the journal, which is accessible via
L<journalctl(1)>. Note
that everything that is written to kmsg (see below) is implicitly stored in the journal as well, the
specific option listed below is hence a superset of this one. (Also note that any external,
additional syslog daemons receive their log data from the journal, too, hence this is the option to
use when logging shall be processed with such a daemon.)

C<kmsg> connects standard output with the kernel log buffer which is accessible via

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

      },
      'ExitType',
      {
        'description' => 'Specifies when the manager should consider the service to be finished. One of C<main> or
C<cgroup>:

It is generally recommended to use C<ExitType>=C<main> when a service has
a known forking model and a main process can reliably be determined. C<ExitType>=C<cgroup> is meant for applications
whose forking model is not known ahead of time and which
might not have a specific main process. It is well suited for transient or automatically generated services,
such as graphical applications inside of a desktop environment.',
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'RemainAfterExit',
      {
        'description' => 'Takes a boolean value that specifies whether
the service shall be considered active even when all its
processes exited. Defaults to C<no>.',
        'type' => 'leaf',
        'value_type' => 'boolean',

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

Note however that reloading a daemon by enqueuing a signal (as with the example line above) is
usually not a good choice, because this is an asynchronous operation and hence not suitable when
ordering reloads of multiple services against each other. It is thus strongly recommended to either
use C<Type>=C<notify-reload> in place of
C<ExecReload>, or to set C<ExecReload> to a command that not only
triggers a configuration reload of the daemon, but also synchronously waits for it to complete. For
example, L<dbus-broker(1)>
uses the following:

    ExecReload=busctl call org.freedesktop.DBus \\
    /org/freedesktop/DBus org.freedesktop.DBus \\
    ReloadConfig
',
        'type' => 'list'
      },
      'ExecStop',
      {
        'cargo' => {
          'type' => 'leaf',
          'value_type' => 'uniline'
        },

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

C<null> connects standard output to C</dev/null>, i.e. everything written
to it will be lost.

C<tty> connects standard output to a tty (as configured via C<TTYPath>,
see below). If the TTY is used for output only, the executed process will not become the controlling process of
the terminal, and will not fail or wait for other processes to release the terminal. Note: if a unit
tries to print multiple lines to a TTY during bootup or shutdown, then there's a chance that those
lines will be broken up by status messages. SetShowStatus() can be used to
prevent this problem. See
L<org.freedesktop.systemd1(5)>
for details.

C<journal> connects standard output with the journal, which is accessible via
L<journalctl(1)>. Note
that everything that is written to kmsg (see below) is implicitly stored in the journal as well, the
specific option listed below is hence a superset of this one. (Also note that any external,
additional syslog daemons receive their log data from the journal, too, hence this is the option to
use when logging shall be processed with such a daemon.)

C<kmsg> connects standard output with the kernel log buffer which is accessible via

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

=head2 ExitType

Specifies when the manager should consider the service to be finished. One of C<main> or
C<cgroup>:

It is generally recommended to use C<ExitType>=C<main> when a service has
a known forking model and a main process can reliably be determined. C<ExitType>=C<cgroup> is meant for applications
whose forking model is not known ahead of time and which
might not have a specific main process. It is well suited for transient or automatically generated services,
such as graphical applications inside of a desktop environment. I< Optional. Type uniline.  > 

=head2 RemainAfterExit

Takes a boolean value that specifies whether
the service shall be considered active even when all its
processes exited. Defaults to C<no>. I< Optional. Type boolean.  > 

=head2 GuessMainPID

Takes a boolean value that specifies whether

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

Note however that reloading a daemon by enqueuing a signal (as with the example line above) is
usually not a good choice, because this is an asynchronous operation and hence not suitable when
ordering reloads of multiple services against each other. It is thus strongly recommended to either
use C<Type>=C<notify-reload> in place of
C<ExecReload>, or to set C<ExecReload> to a command that not only
triggers a configuration reload of the daemon, but also synchronously waits for it to complete. For
example, L<dbus-broker(1)>
uses the following:

    ExecReload=busctl call org.freedesktop.DBus \
    /org/freedesktop/DBus org.freedesktop.DBus \
    ReloadConfig
. I< Optional. Type list of uniline.  > 

=head2 ExecStop

Commands to execute to stop the service started via
C<ExecStart>. This argument takes multiple command lines, following the same scheme
as described for C<ExecStart> above. Use of this setting is optional. After the
commands configured in this option are run, it is implied that the service is stopped, and any
processes remaining for it are terminated according to the C<KillMode> setting (see

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

referred to using C<%i> and other specifiers, see below.

Unit files may contain additional options on top of those listed here. If systemd encounters an
unknown option, it will write a warning log message but continue loading the unit. If an option or
section name is prefixed with C<X->, it is ignored completely by systemd. Options within an
ignored section do not need the prefix. Applications may use this to include additional information in
the unit files. To access those options, applications need to parse the unit files on their own.

Units can be aliased (have an alternative name), by creating a symlink from the new name to the
existing name in one of the unit search paths. For example, C<systemd-networkd.service>
has the alias C<dbus-org.freedesktop.network1.service>, created during installation as
a symlink, so when systemd is asked through D-Bus to load
C<dbus-org.freedesktop.network1.service>, it'll load
C<systemd-networkd.service>. As another example, C<default.target> \x{2014}
the default system target started at boot \x{2014} is commonly aliased to either
C<multi-user.target> or C<graphical.target> to select what is started
by default. Alias names may be used in commands like disable,
start, stop, status, and similar, and in all
unit dependency directives, including C<Wants>, C<Requires>,
C<Before>, C<After>. Aliases cannot be used with the
preset command.

Aliases obey the following restrictions: a unit of a certain type (C<.service>,