Config-Model-Systemd

 view release on metacpan or  search on metacpan

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

are not available), and the unit should be written in a way that does not solely rely on this setting
for security.

Note that when this option is enabled for a service hostname changes no longer propagate from
the system into the service, it is hence not suitable for services that need to take notice of system
hostname changes dynamically.

Note that this option does not prevent changing system hostname via hostnamectl.
However, C<User> and C<Group> may be used to run as an unprivileged user
to disallow changing system hostname. See SetHostname() in
L<org.freedesktop.hostname1(5)>
for more details.',
        'replace' => {
          '0' => 'no',
          '1' => 'yes',
          'false' => 'no',
          'true' => 'yes'
        },
        'type' => 'leaf',
        'upstream_default' => 'no',
        'value_type' => 'enum'

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',
        'upstream_default' => 'no',

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

    ExecReload=kill -HUP $MAINPID

Note however that reloading a daemon by enqueuing a signal without completion notification
(as is the case 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=notify-reload>,
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


This setting can be combined with C<Type=notify-reload>, in which case
the service main process is signaled after all specified command lines finish execution. Specially,
if C<RELOADING=1> notification is received before C<ExecReload>
completes, the signaling is skipped and the service manager immediately starts listening for
C<READY=1>.',
        'type' => 'list'
      },

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

are not available), and the unit should be written in a way that does not solely rely on this setting
for security.

Note that when this option is enabled for a service hostname changes no longer propagate from
the system into the service, it is hence not suitable for services that need to take notice of system
hostname changes dynamically.

Note that this option does not prevent changing system hostname via hostnamectl.
However, C<User> and C<Group> may be used to run as an unprivileged user
to disallow changing system hostname. See SetHostname() in
L<org.freedesktop.hostname1(5)>
for more details. I< Optional. Type enum. choice: 'no', 'private', 'yes'.  > 

=over 4

=item upstream_default value :

no

=back

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.  > 

=over 4

=item upstream_default value :

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

    ExecReload=kill -HUP $MAINPID

Note however that reloading a daemon by enqueuing a signal without completion notification
(as is the case 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=notify-reload>,
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


This setting can be combined with C<Type=notify-reload>, in which case
the service main process is signaled after all specified command lines finish execution. Specially,
if C<RELOADING=1> notification is received before C<ExecReload>
completes, the signaling is skipped and the service manager immediately starts listening for
C<READY=1>. I< Optional. Type list of uniline.  > 

=head2 ExecReloadPost

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>,