systemd-service-unit
Example:
# Create a systemd-unit file for the 'keycloak' service. - systemd-service-unit: name: keycloak desc: keycloak authentication service service_config: - KEYCLOAK_CONFIG: standalone.xml KEYCLOAK_MODE: standalone KEYCLOAK_BIND: 127.0.0.1 ServiceType: idle ServiceEnvironment: LAUNCH_JBOSS_IN_BACKGROUND=1 ServiceUser: keycloak ServiceGroup: keycloak ExecStart: /usr/local/bin/keycloak-launch.sh ${KEYCLOAK_MODE} ${KEYCLOAK_CONFIG} ${KEYCLOAK_BIND} UnitBefore: - httpd.service UnitAfter: - network.target ServiceTimeoutStartSec: 600 ServiceTimeoutStopSec: 600 InstallWantedBy: - multi-user.target enabled: true started: true
Description
Add a systemd unit for a service.
This does not create the user from the 'service_user' parameter, nor the group from 'service_group'.
Variables
| Name | Type | Default | Description |
|---|---|---|---|
|
string | -- | The name of the service. Required |
|
['list', 'string'] | -- | Commands with their arguments that are executed when this service is started. The value is split into zero or more command lines according to the rules described below (see section 'Command Lines' below). Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified. Commands may be specified by providing multiple command lines in the same directive, or alternatively, this directive may be specified more than once with the same effect. If the empty string is assigned to this option, the list of commands to start is reset, prior assignments of this option will have no effect. If no ExecStart= is specified, then the service must have RemainAfterExit=yes and at least one ExecStop= line set. (Services lacking both ExecStart= and ExecStop= are not valid.) Required |
|
boolean | -- | Whether to enable the service. |
|
list | -- | A space-separated list of additional names this unit shall be installed under. The names listed here must have the same suffix (i.e. type) as the unit filename. This option may be specified more than once, in which case all listed names are used. At installation time, systemctl enable will create symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support aliasing. |
|
list | -- | Additional units to install/deinstall when this unit is installed/deinstalled. If the user requests installation/deinstallation of a unit with this option configured, systemctl enable and systemctl disable will automatically install/uninstall units listed in this option as well. This option may be used more than once, or a space-separated list of unit names may be given. |
|
string | -- | In template unit files, this specifies for which instance the unit shall be enabled if the template is enabled without any explicitly set instance. This option has no effect in non-template unit files. The specified string must be usable as instance identifier. |
|
list | -- | This option may be used more than once, or a space-separated list of unit names may be given. A symbolic link is created in the .wants/ or .requires/ directory of each of the listed units when this unit is installed by systemctl enable. This has the effect that a dependency of type Wants= or Requires= is added from the listed unit to the current unit. The primary result is that the current unit will be started when the listed unit is started. See the description of Wants= and Requires= in the [Unit] section for details. WantedBy=foo.service in a service bar.service is mostly equivalent to Alias=foo.service.wants/bar.service in the same file. In case of template units, systemctl enable must be called with an instance name, and this instance will be added to the .wants/ or .requires/ list of the listed unit. E.g. WantedBy=getty.target in a service [email protected] will result in systemctl enable [email protected] creating a getty.target.wants/[email protected] link to [email protected]. |
|
list | -- | This option may be used more than once, or a space-separated list of unit names may be given. A symbolic link is created in the .wants/ or .requires/ directory of each of the listed units when this unit is installed by systemctl enable. This has the effect that a dependency of type Wants= or Requires= is added from the listed unit to the current unit. The primary result is that the current unit will be started when the listed unit is started. See the description of Wants= and Requires= in the [Unit] section for details. WantedBy=foo.service in a service bar.service is mostly equivalent to Alias=foo.service.wants/bar.service in the same file. In case of template units, systemctl enable must be called with an instance name, and this instance will be added to the .wants/ or .requires/ list of the listed unit. E.g. WantedBy=getty.target in a service [email protected] will result in systemctl enable [email protected] creating a getty.target.wants/[email protected] link to [email protected]. |
|
string | -- | The instance name, in case this unit is enabled or started, and the 'is_template_unit' flag is set. |
|
boolean | False | Whether this unit is a 'template unit' (can be parametrized and instance name ends with '@'). |
|
list | -- | Controls which capabilities to include in the ambient capability set for the executed process. Takes a whitespace-separated list of capability names, e.g. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. This option may appear more than once in which case the ambient capability sets are merged (see the above examples in CapabilityBoundingSet=). If the list of capabilities is prefixed with '~', all but the listed capabilities will be included, the effect of the assignment inverted. If the empty string is assigned to this option, the ambient capability set is reset to the empty capability set, and all prior settings have no effect. If set to '~' (without any further argument), the ambient capability set is reset to the full set of available capabilities, also undoing any previous settings. Note that adding capabilities to ambient capability set adds them to the process's inherited capability set. Ambient capability sets are useful if you want to execute a process as a non-privileged user but still want to give it some capabilities. Note that in this case option keep-caps is automatically added to SecureBits= to retain the capabilities over the user change. AmbientCapabilities= does not affect commands prefixed with '+'. |
|
string | -- | Takes a D-Bus bus name that this service is reachable as. This option is mandatory for services where Type= is set to dbus. |
|
list | -- | Controls which capabilities to include in the capability bounding set for the executed process. See capabilities(7) for details. Takes a whitespace-separated list of capability names, e.g. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Capabilities listed will be included in the bounding set, all others are removed. If the list of capabilities is prefixed with '~', all but the listed capabilities will be included, the effect of the assignment inverted. Note that this option also affects the respective capabilities in the effective, permitted and inheritable capability sets. If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced. This option may appear more than once, in which case the bounding sets are merged by OR, or by AND if the lines are prefixed with '~' (see below). If the empty string is assigned to this option, the bounding set is reset to the empty capability set, and all prior settings have no effect. If set to '~' (without any further argument), the bounding set is reset to the full set of available capabilities, also undoing any previous settings. This does not affect commands prefixed with '+'. Example: if a unit has the following, CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=CAP_B CAP_C then CAP_A, CAP_B, and CAP_C are set. If the second line is prefixed with '~', e.g., CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=~CAP_B CAP_C then, only CAP_A is set. |
|
dict | ordereddict() | A map of key/value-pairs to put into a '/etc/conf.d/ This can be used in addition or instead of 'service_environment' and 'service_environment_file'. It is meant as a short-cut, to not have to create the config file (in '/etc/conf.d') in an extra step. |
|
boolean | -- | Turns on delegation of further resource control partitioning to processes of the unit. Units where this is enabled may create and manage their own private subhierarchy of control groups below the control group of the unit itself. For unprivileged services (i.e. those using the User= setting) the unit's control group will be made accessible to the relevant user. When enabled the service manager will refrain from manipulating control groups or moving processes below the unit's control group, so that a clear concept of ownership is established: the control group tree above the unit's control group (i.e. towards the root control group) is owned and managed by the service manager of the host, while the control group tree below the unit's control group is owned and managed by the unit itself. Takes either a boolean argument or a list of control group controller names. If true, delegation is turned on, and all supported controllers are enabled for the unit, making them available to the unit's processes for management. If false, delegation is turned off entirely (and no additional controllers are enabled). If set to a list of controllers, delegation is turned on, and the specified controllers are enabled for the unit. Note that additional controllers than the ones specified might be made available as well, depending on configuration of the containing slice unit or other units contained in it. Note that assigning the empty string will enable delegation, but reset the list of controllers, all assignments prior to this will have no effect. Defaults to false. Note that controller delegation to less privileged code is only safe on the unified control group hierarchy. Accordingly, access to the specified controllers will not be granted to unprivileged services on the legacy hierarchy, even when requested. The following controller names may be specified: cpu, cpuacct, io, blkio, memory, devices, pids. Not all of these controllers are available on all kernels however, and some are specific to the unified hierarchy while others are specific to the legacy hierarchy. Also note that the kernel might support further controllers, which aren't covered here yet as delegation is either not supported at all for them or not defined cleanly. For further details on the delegation model consult Control Group APIs and Delegation. |
|
dict | -- | Sets environment variables for executed processes. Takes a space-separated list of variable assignments. This option may be specified more than once, in which case all listed variables will be set. If the same variable is set twice, the later setting will override the earlier setting. If the empty string is assigned to this option, the list of environment variables is reset, all prior assignments have no effect. Variable expansion is not performed inside the strings, however, specifier expansion is possible. The $ character has no special meaning. If you need to assign a value containing spaces or the equals sign to a variable, use double quotes (') for the assignment. Example: Environment='VAR1=word1 word2' VAR2=word3 'VAR3=$word 5 6'
gives three variables 'VAR1', 'VAR2', 'VAR3' with the values 'word1 word2', 'word3', '$word 5 6'. See environ(7) for details about environment variables. Note that environment variables are not suitable for passing secrets (such as passwords, key material, …) to service processes. Environment variables set for a unit are exposed to unprivileged clients via D-Bus IPC, and generally not understood as being data that requires protection. Moreover, environment variables are propagated down the process tree, including across security boundaries (such as setuid/setgid executables), and hence might leak to processes that should not have access to the secret data. |
|
['list', 'string'] | [] | Similar to Environment= but reads the environment variables from a text file. The text file should contain new-line-separated variable assignments. Empty lines, lines without an '=' separator, or lines starting with ; or # will be ignored, which may be used for commenting. A line ending with a backslash will be concatenated with the following one, allowing multiline variable definitions. The parser strips leading and trailing whitespace from the values of assignments, unless you use double quotes ('). The argument passed should be an absolute filename or wildcard expression, optionally prefixed with '-', which indicates that if the file does not exist, it will not be read and no error or warning message is logged. This option may be specified more than once in which case all specified files are read. If the empty string is assigned to this option, the list of file to read is reset, all prior assignments have no effect. The files listed with this directive will be read shortly before the process is executed (more specifically, after all processes from a previous unit state terminated. This means you can generate these files in one unit state, and read it with this option in the next). Settings from these files override settings made with Environment=. If the same variable is set twice from these files, the files will be read in the order they are specified and the later setting will override the earlier setting. |
|
['string', 'list'] | -- | Commands to execute to trigger a configuration reload in the service. This argument takes multiple command lines, following the same scheme as described for ExecStart= above. Use of this setting is optional. Specifier and environment variable substitution is supported here following the same scheme as for ExecStart=. One additional, special environment variable is set: if known, $MAINPID is set to the main process of the daemon, and may be used for command lines like the following: /bin -HUP $MAINPID
Note however that reloading a daemon by sending a signal (as with the example line above) is usually not a good choice, because this is an asynchronous operation and hence not suitable to order reloads of multiple services against each other. It is strongly recommended to set ExecReload= to a command that not only triggers a configuration reload of the daemon, but also synchronously waits for it to complete. |
|
['list', 'string'] | -- | Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=, except that multiple command lines are allowed and the commands are executed one after the other, serially. If any of those commands (not prefixed with '-') fail, the rest are not executed and the unit is considered failed. ExecStart= commands are only run after all ExecStartPre= commands that were not prefixed with a '-' exit successfully. ExecStartPost= commands are only run after the commands specified in ExecStart= have been invoked successfully, as determined by Type= (i.e. the process has been started for Type=simple or Type=idle, the last ExecStart= process exited successfully for Type=oneshot, the initial process exited successfully for Type=forking, 'READY=1' is sent for Type=notify, or the BusName= has been taken for Type=dbus). Note that ExecStartPre= may not be used to start long-running processes. All processes forked off by processes invoked via ExecStartPre= will be killed before the next service process is run. Note that if any of the commands specified in ExecStartPre=, ExecStart=, or ExecStartPost= fail (and are not prefixed with '-', see above) or time out before the service is fully up, execution continues with commands specified in ExecStopPost=, the commands in ExecStop= are skipped. |
|
['list', 'string'] | -- | Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=, except that multiple command lines are allowed and the commands are executed one after the other, serially. If any of those commands (not prefixed with '-') fail, the rest are not executed and the unit is considered failed. ExecStart= commands are only run after all ExecStartPre= commands that were not prefixed with a '-' exit successfully. ExecStartPost= commands are only run after the commands specified in ExecStart= have been invoked successfully, as determined by Type= (i.e. the process has been started for Type=simple or Type=idle, the last ExecStart= process exited successfully for Type=oneshot, the initial process exited successfully for Type=forking, 'READY=1' is sent for Type=notify, or the BusName= has been taken for Type=dbus). Note that ExecStartPre= may not be used to start long-running processes. All processes forked off by processes invoked via ExecStartPre= will be killed before the next service process is run. Note that if any of the commands specified in ExecStartPre=, ExecStart=, or ExecStartPost= fail (and are not prefixed with '-', see above) or time out before the service is fully up, execution continues with commands specified in ExecStopPost=, the commands in ExecStop= are skipped. |
|
['string', 'list'] | -- | Commands to execute to stop the service started via ExecStart=. This argument takes multiple command lines, following the same scheme as described for 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 KillMode= setting (see systemd.kill(5)). If this option is not specified, the process is terminated by sending the signal specified in KillSignal= when service stop is requested. Specifier and environment variable substitution is supported (including $MAINPID, see above). Note that it is usually not sufficient to specify a command for this setting that only asks the service to terminate (for example, by queuing some form of termination signal for it), but does not wait for it to do so. Since the remaining processes of the services are killed according to KillMode= and KillSignal= as described above immediately after the command exited, this may not result in a clean stop. The specified command should hence be a synchronous operation, not an asynchronous one. Note that the commands specified in ExecStop= are only executed when the service started successfully first. They are not invoked if the service was never started at all, or in case its start-up failed, for example because any of the commands specified in ExecStart=, ExecStartPre= or ExecStartPost= failed (and weren't prefixed with '-', see above) or timed out. Use ExecStopPost= to invoke commands when a service failed to start up correctly and is shut down again. Also note that the stop operation is always performed if the service started successfully, even if the processes in the service terminated on their own or were killed. The stop commands must be prepared to deal with that case. $MAINPID will be unset if systemd knows that the main process exited by the time the stop commands are called. Service restart requests are implemented as stop operations followed by start operations. This means that ExecStop= and ExecStopPost= are executed during a service restart operation. It is recommended to use this setting for commands that communicate with the service requesting clean termination. For post-mortem clean-up steps use ExecStopPost= instead. |
|
['list', 'string'] | -- | Additional commands that are executed after the service is stopped. This includes cases where the commands configured in ExecStop= were used, where the service does not have any ExecStop= defined, or where the service exited unexpectedly. This argument takes multiple command lines, following the same scheme as described for ExecStart=. Use of these settings is optional. Specifier and environment variable substitution is supported. Note that – unlike ExecStop= – 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 been terminated 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 $SERVICE_RESULT, $EXIT_CODE and $EXIT_STATUS environment variables, see systemd.exec(5) for details. |
|
string | -- | Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or a numeric ID as argument. For system services (services run by the system service manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of systemd --user), the default is 'root', but User= may be used to specify a different user. For user services of any other user, switching user identity is not permitted, hence the only valid setting is the same user the user's service manager is running as. If no group is set, the default group of the user is used. This setting does not affect commands whose command line is prefixed with '+'. Note that restrictions on the user/group name syntax are enforced: the specified name must consist only of the characters a-z, A-Z, 0-9, '' and '-', except for the first character which must be one of a-z, A-Z or '' (i.e. numbers and '-' are not permitted as first character). The user/group name must have at least one character, and at most 31. These restrictions are enforced in order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux systems. When used in conjunction with DynamicUser= the user/group name specified is dynamically allocated at the time the service is started, and released at the time the service is stopped — unless it is already allocated statically (see below). If DynamicUser= is not used the specified user and group must have been created statically in the user database no later than the moment the service is started, for example using the sysusers.d(5) facility, which is applied at boot or package install time. |
|
boolean | -- | Takes a boolean value that specifies whether systemd should try to guess the main PID of a service if it cannot be determined reliably. This option is ignored unless Type=forking is set and PIDFile= is unset because for the other types or with an explicitly configured PID file, the main PID is always known. The guessing algorithm might come to incorrect conclusions if a daemon consists of more than one process. If the main PID cannot be determined, failure detection and automatic restarting of a service will not work reliably. Defaults to yes. |
|
string | -- | If set to 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 ExecStop=). If set to process, only the main process itself is killed. If set to mixed, the SIGTERM signal (see below) is sent to the main process while the subsequent SIGKILL signal (see below) is sent to all remaining processes of the unit's control group. If set to none, no process is killed. In this case, only the stop command will be executed on unit stop, but no process be killed otherwise. Processes remaining alive after stop are left in their control group and the control group continues to exist after stop unless it is empty. Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal=). Optionally, this is immediately followed by a SIGHUP (if enabled with SendSIGHUP=). If processes still remain after the main process of a unit has exited or the delay configured via the TimeoutStopSec= has passed, the termination request is repeated with the SIGKILL signal or the signal specified via FinalKillSignal= (unless this is disabled via the SendSIGKILL= option). See kill(2) for more information. Defaults to control-group. |
|
string | -- | Specifies which signal to use when killing a service. This controls the signal that is sent as first step of shutting down a unit (see above), and is usually followed by SIGKILL (see above and below). For a list of valid signals, see signal(7). Defaults to SIGTERM. |
|
list | -- | Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the resource limit concept. Resource limits may be specified in two formats: either as single value to set a specific soft and hard limit to the same value, or as colon-separated pair soft:hard to set both limits individually (e.g. 'LimitAS=4G:16G'). Use the string infinity to configure no limit on a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits measured in bytes (e.g. LimitAS=16G). For the limits referring to time values, the usual time units ms, s, min, h and so on may be used (see systemd.time(7) for details). Note that if no time unit is specified for LimitCPU= the default unit of seconds is implied, while for LimitRTTIME= the default unit of microseconds is implied. Also, note that the effective granularity of the limits might influence their enforcement. For example, time limits specified for LimitCPU= will be rounded up implicitly to multiples of 1s. For LimitNICE= the value may be specified in two syntaxes: if prefixed with '+' or '-', the value is understood as regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1). Note that most process resource limits configured with these options are per-process, and processes may fork in order to acquire a new set of resources that are accounted independently of the original process, and may thus escape limits set. Also note that LimitRSS= is not implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource controls listed in systemd.resource-control(5) over these per-process limits, as they apply to services as a whole, may be altered dynamically at runtime, and are generally more expressive. For example, MemoryLimit= is a more powerful (and working) replacement for LimitRSS=. For system units these resource limits may be chosen freely. For user units however (i.e. units run by a per-user instance of systemd(1)), these limits are bound by (possibly more restrictive) per-user limits enforced by the OS. Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=, DefaultLimitFSIZE=, … options available in systemd-system.conf(5), and – if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user services, see above). |
|
boolean | -- | Takes a boolean argument. If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable are prohibited. Specifically, a system call filter is added that rejects mmap(2) system calls with both PROT_EXEC and PROT_WRITE set, mprotect(2) or pkey_mprotect(2) system calls with PROT_EXEC set and shmat(2) system calls with SHM_EXEC set. Note that this option is incompatible with programs and libraries that generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code 'trampoline' feature of various C compilers. This option improves service security, as it makes harder for software exploits to change running code dynamically. However, the protection can be circumvented, if the service can write to a filesystem, which is not mounted with noexec (such as /dev/shm), or it can use memfd_create(). This can be prevented by making such file systems inaccessible to the service (e.g. InaccessiblePaths=/dev/shm) and installing further system call filters (SystemCallFilter=~memfd_create). Note that this feature is fully available on x86-64, and partially on x86. Specifically, the shmat() protection is not available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this option. Specifically, it is recommended to combine this option with SystemCallArchitectures=native or similar. If running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=), NoNewPrivileges=yes is implied. |
|
boolean | -- | Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that a process and its children can never elevate privileges again. Defaults to false, but certain settings override this and ignore the value of this setting. This is the case when SystemCallFilter=, SystemCallArchitectures=, RestrictAddressFamilies=, RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=, MemoryDenyWriteExecute=, RestrictRealtime=, RestrictSUIDSGID=, DynamicUser= or LockPersonality= are specified. Note that even if this setting is overridden by them, systemctl show shows the original value of this setting. Also see No New Privileges Flag. |
|
boolean | -- | Takes a boolean argument. If true, the permission-related execution options, as configured with User= and similar options (see systemd.exec(5) for more information), are only applied to the process started with ExecStart=, and not to the various other ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, and ExecStopPost= commands. If false, the setting is applied to all configured commands the same way. Defaults to false. Deprecated. |
|
string | -- | Takes a path referring to the PID file of the service. Usage of this option is recommended for services where Type= is set to forking. The path specified typically points to a file below /run/. If a relative path is specified it is hence prefixed with /run/. The service manager will read the PID of the main process of the service from this file after start-up of the service. The service manager will not write to the file configured here, although it will remove the file after the service has shut down if it still exists. The PID file does not need to be owned by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced: the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the PID file must refer to a process already belonging to the service. |
|
boolean | -- | Takes a boolean argument. If true, sets up a new /dev mount for the executed processes and only adds API pseudo devices such as /dev/null, /dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it, but no physical devices such as /dev/sda, system memory /dev/mem, system ports /dev/port and others. This is useful to securely turn off physical device access by the executed process. Defaults to false. Enabling this option will install a system call filter to block low-level I/O system calls that are grouped in the @raw-io set, will also remove CAP_MKNOD and CAP_SYS_RAWIO from the capability bounding set for the unit (see above), and set DevicePolicy=closed (see systemd.resource-control(5) for details). Note that using this setting will disconnect propagation of mounts from the service to the host (propagation in the opposite direction continues to work). This means that this setting may not be used for services which shall be able to install mount points in the main mount namespace. The new /dev will be mounted read-only and 'noexec'. The latter may break old programs which try to set up executable memory by using mmap(2) of /dev/zero instead of using MAP_ANON. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. If turned on and if running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=), NoNewPrivileges=yes is implied. Note that the implementation of this setting might be impossible (for example if mount namespaces are not available), and the unit should be written in a way that does not solely rely on this setting for security. This option is only available for system services and is not supported for services running in per-user instances of the service manager. |
|
boolean | -- | Takes a boolean argument. If true, sets up a new file system namespace for the executed processes and mounts private /tmp and /var/tmp directories inside it that is not shared by processes outside of the namespace. This is useful to secure access to temporary files of the process, but makes sharing between processes via /tmp or /var/tmp impossible. If this is enabled, all temporary files created by a service in these directories will be removed after the service is stopped. Defaults to false. It is possible to run two or more units within the same private /tmp and /var/tmp namespace by using the JoinsNamespaceOf= directive, see systemd.unit(5) for details. This setting is implied if DynamicUser= is set. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Enabling this setting has the side effect of adding Requires= and After= dependencies on all mount units necessary to access /tmp and /var/tmp. Moreover an implicitly After= ordering on systemd-tmpfiles-setup.service(8) is added. Note that the implementation of this setting might be impossible (for example if mount namespaces are not available), and the unit should be written in a way that does not solely rely on this setting for security. This option is only available for system services and is not supported for services running in per-user instances of the service manager. |
|
n/a | -- | Takes a boolean argument or the special values 'read-only' or 'tmpfs'. If true, the directories /home, /root and /run/user are made inaccessible and empty for processes invoked by this unit. If set to 'read-only', the three directories are made read-only instead. If set to 'tmpfs', temporary file systems are mounted on the three directories in read-only mode. The value 'tmpfs' is useful to hide home directories not relevant to the processes invoked by the unit, while necessary directories are still visible by combining with BindPaths= or BindReadOnlyPaths=. Setting this to 'yes' is mostly equivalent to set the three directories in InaccessiblePaths=. Similarly, 'read-only' is mostly equivalent to ReadOnlyPaths=, and 'tmpfs' is mostly equivalent to TemporaryFileSystem=. It is recommended to enable this setting for all long-running services (in particular network-facing ones), to ensure they cannot get access to private user data, unless the services actually require access to the user's private data. This setting is implied if DynamicUser= is set. This setting cannot ensure protection in all cases. In general it has the same limitations as ReadOnlyPaths=, see below. This option is only available for system services and is not supported for services running in per-user instances of the service manager. |
|
string | -- | Takes a boolean argument or the special values 'full' or 'strict'. If true, mounts the /usr and /boot directories read-only for processes invoked by this unit. If set to 'full', the /etc directory is mounted read-only, too. If set to 'strict' the entire file system hierarchy is mounted read-only, except for the API file system subtrees /dev, /proc and /sys (protect these directories using PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=). This setting ensures that any modification of the vendor-supplied operating system (and optionally its configuration, and local mounts) is prohibited for the service. It is recommended to enable this setting for all long-running services, unless they are involved with system updates or need to modify the operating system in other ways. If this option is used, ReadWritePaths= may be used to exclude specific directories from being made read-only. This setting is implied if DynamicUser= is set. This setting cannot ensure protection in all cases. In general it has the same limitations as ReadOnlyPaths=, see below. Defaults to off. |
|
boolean | -- | Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. Defaults to no. |
|
string | -- | 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 ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or 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 no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted. If set to on-success, it will be restarted only when the service process exits cleanly. In this context, a clean exit means an exit code of 0, or one of the signals SIGHUP, SIGINT, SIGTERM or SIGPIPE, and additionally, exit statuses and signals specified in SuccessExitStatus=. If set to 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 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 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 on-watchdog, the service will be restarted only if the watchdog timeout for the service expires. If set to always, the service will be restarted regardless of whether it exited cleanly or not, got terminated abnormally by a signal, or hit a timeout. |
|
list | -- | a list of exit status definitions that, when returned by the main service process, will force automatic service restarts, regardless of the restart setting configured with Restart=. |
|
integer | -- | Configures the time to sleep before restarting a service (as configured with Restart=). Takes a unit-less value in seconds, or a time span value such as '5min 20s'. Defaults to 100ms. |
|
list | -- | Create a runtime directory for a service. |
|
string | -- | Sets the permission for the 'service_runtime_directory' values. |
|
list | -- | Controls the secure bits set for the executed process. Takes a space-separated combination of options from the following list: keep-caps, keep-caps-locked, no-setuid-fixup, no-setuid-fixup-locked, noroot, and noroot-locked. This option may appear more than once, in which case the secure bits are ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands prefixed with '+'. See capabilities(7) for details. |
|
list | -- | Takes a list of exit status definitions that, when returned by the main service process, will be considered successful termination, in addition to the normal successful exit code 0 and the signals SIGHUP, SIGINT, SIGTERM, and SIGPIPE. Exit status definitions can be numeric exit codes, termination code names, or termination signal names, separated by spaces. See the Process Exit Codes section in systemd.exec(5) for a list of termination codes names (for this setting only the part without the 'EXIT_' or 'EX_' prefix should be used). See signal(7) for a list of signal names. This option may appear more than once, in which case the list of successful exit statuses is merged. If the empty string is assigned to this option, the list is reset, all prior assignments of this option will have no effect. |
|
list | -- | Takes a space-separated list of architecture identifiers. Selects from which architectures system calls may be invoked on this system. This may be used as an effective way to disable invocation of non-native binaries system-wide, for example to prohibit execution of 32-bit x86 binaries on 64-bit x86-64 systems. This option operates system-wide, and acts similar to the SystemCallArchitectures= setting of unit files, see systemd.exec(5) for details. This setting defaults to the empty list, in which case no filtering of system calls based on architecture is applied. Known architecture identifiers are 'x86', 'x86-64', 'x32', 'arm' and the special identifier 'native'. The latter implicitly maps to the native architecture of the system (or more specifically, the architecture the system manager was compiled for). Set this setting to 'native' to prohibit execution of any non-native binaries. When a binary executes a system call of an architecture that is not listed in this setting, it will be immediately terminated with the SIGSYS signal. |
|
string | -- | Specify the maximum number of tasks that may be created in the unit. This ensures that the number of tasks accounted for the unit (see above) stays below a specific limit. This either takes an absolute number of tasks or a percentage value that is taken relative to the configured maximum number of tasks on the system. If assigned the special value 'infinity', no tasks limit is applied. This controls the 'pids.max' control group attribute. For details about this control group attribute, see pids.txt. The system default for this setting may be controlled with DefaultTasksMax= in systemd-system.conf(5). |
|
integer | -- | A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified value. |
|
integer | -- | 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. Takes a unit-less value in seconds, or a time span value such as '5min 20s'. Pass 'infinity' to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the manager configuration file, except when Type=oneshot is used, in which case the timeout is disabled by default (see systemd-system.conf(5)). If a service of Type=notify sends 'EXTEND_TIMEOUT_USEC=…', this may cause the start time to be extended beyond TimeoutStartSec=. The first receipt of this message must occur before TimeoutStartSec= is exceeded, and once the start time has exended beyond TimeoutStartSec=, the service manager will allow the service to continue to start, provided the service repeats 'EXTEND_TIMEOUT_USEC=…' within the interval specified until the service startup status is finished by 'READY=1'. (see sd_notify(3)). |
|
integer | -- | This option serves two purposes. First, it configures the time to wait for each ExecStop= command. If any of them times out, subsequent ExecStop= commands are skipped and the service will be terminated by SIGTERM. If no ExecStop= commands are specified, the service gets the SIGTERM immediately. Second, it configures the time to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated by SIGKILL (see KillMode= in systemd.kill(5)). Takes a unit-less value in seconds, or a time span value such as '5min 20s'. Pass 'infinity' to disable the timeout logic. Defaults to DefaultTimeoutStopSec= from the manager configuration file (see systemd-system.conf(5)). If a service of Type=notify sends 'EXTEND_TIMEOUT_USEC=…', this may cause the stop time to be extended beyond TimeoutStopSec=. The first receipt of this message must occur before TimeoutStopSec= is exceeded, and once the stop time has exended beyond TimeoutStopSec=, the service manager will allow the service to continue to stop, provided the service repeats 'EXTEND_TIMEOUT_USEC=…' within the interval specified, or terminates itself (see sd_notify(3)). |
|
string | simple | Configures the process start-up type for this service unit. One of simple, exec, forking, oneshot, dbus, notify or idle: If set to simple (the default if ExecStart= is specified but neither Type= nor BusName= are), the service manager will consider the unit started immediately after the main service process has been forked off. It is expected that the process configured with ExecStart= is the main process of the service. In this mode, if the process offers functionality to other processes on the system, its communication channels should be installed before the service is started up (e.g. sockets set up by systemd, via socket activation), as the service manager will immediately proceed starting follow-up units, right after creating the main service process, and before executing the service's binary. Note that this means systemctl start command lines for simple services will report success even if the service's binary cannot be invoked successfully (for example because the selected User= doesn't exist, or the service binary is missing). The exec type is similar to simple, but the service manager will consider the unit started immediately after the main service binary has been executed. The service manager will delay starting of follow-up units until that point. (Or in other words: simple proceeds with further jobs right after fork() returns, while exec will not proceed before both fork() and execve() in the service process succeeded.) Note that this means systemctl start command lines for exec services will report failure when the service's binary cannot be invoked successfully (for example because the selected User= doesn't exist, or the service binary is missing). If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main service process, and the service manager will consider the unit started when the parent process exits. This is the behavior of traditional UNIX services. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can reliably identify the main process of the service. systemd will proceed with starting follow-up units as soon as the parent process exits. Behavior of oneshot is similar to simple; however, the service manager will consider the unit started after the main process exits. It will then start follow-up units. RemainAfterExit= is particularly useful for this type of service. Type=oneshot is the implied default if neither Type= nor ExecStart= are specified. Behavior of dbus is similar to simple; however, it is expected that the service acquires a name on the D-Bus bus, as configured by BusName=. systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired. Service units with this option configured implicitly gain dependencies on the dbus.socket unit. This type is the default if BusName= is specified. Behavior of notify is similar to exec; however, it is expected that the service sends a notification message via sd_notify(3) or an equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after this notification message has been sent. If this option is used, NotifyAccess= (see below) should be set to open access to the notification socket provided by systemd. If NotifyAccess= is missing or set to none, it will be forcibly set to main. Note that currently Type=notify will not work if used in combination with PrivateNetwork=yes. Behavior of idle is very similar to simple; however, actual execution of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving of output of shell services with the status output on the console. Note that this type is useful only to improve console output, it is not useful as a general unit ordering tool, and the effect of this service type is subject to a 5s timeout, after which the service program is invoked anyway. It is generally recommended to use Type=simple for long-running services whenever possible, as it is the simplest and fastest option. However, as this service type won't propagate service start-up failures and doesn't allow ordering of other units against completion of initialization of the service (which for example is useful if clients need to connect to the service through some form of IPC, and the IPC channel is only established by the service itself — in contrast to doing this ahead of time through socket or bus activation or similar), it might not be sufficient for many cases. If so, notify or dbus (the latter only in case the service provides a D-Bus interface) are the preferred options as they allow service program code to precisely schedule when to consider the service started up successfully and when to proceed with follow-up units. The notify service type requires explicit support in the service codebase (as sd_notify() or an equivalent API needs to be invoked by the service at the appropriate time) — if it's not supported, then forking is an alternative: it supports the traditional UNIX service start-up protocol. Finally, exec might be an option for cases where it is enough to ensure the service binary is invoked, and where the service binary itself executes no or little initialization on its own (and its initialization is unlikely to fail). Note that using any type other than simple possibly delays the boot process, as the service manager needs to wait for service initialization to complete. It is hence recommended not to needlessly use any types other than simple. (Also note it is generally not recommended to use idle or oneshot for long-running services.) |
|
string | -- | Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or a numeric ID as argument. For system services (services run by the system service manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of systemd --user), the default is 'root', but User= may be used to specify a different user. For user services of any other user, switching user identity is not permitted, hence the only valid setting is the same user the user's service manager is running as. If no group is set, the default group of the user is used. This setting does not affect commands whose command line is prefixed with '+'. Note that restrictions on the user/group name syntax are enforced: the specified name must consist only of the characters a-z, A-Z, 0-9, '' and '-', except for the first character which must be one of a-z, A-Z or '' (i.e. numbers and '-' are not permitted as first character). The user/group name must have at least one character, and at most 31. These restrictions are enforced in order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux systems. When used in conjunction with DynamicUser= the user/group name specified is dynamically allocated at the time the service is started, and released at the time the service is stopped — unless it is already allocated statically (see below). If DynamicUser= is not used the specified user and group must have been created statically in the user database no later than the moment the service is started, for example using the sysusers.d(5) facility, which is applied at boot or package install time. |
|
string | -- | Takes a directory path relative to the service's root directory specified by RootDirectory=, or the special value '~'. Sets the working directory for executed processes. If set to '~', the home directory of the user specified in User= is used. If not set, defaults to the root directory when systemd is running as a system instance and the respective user's home directory if run as user. If the setting is prefixed with the '-' character, a missing working directory is not considered fatal. If RootDirectory=/RootImage= is not set, then WorkingDirectory= is relative to the root of the system running the service manager. Note that setting this parameter might result in additional dependencies to be added to the unit (see above). |
|
boolean | -- | Whether to start the service. |
|
list | -- | These two settings ('Before', 'After') expect a space-separated list of unit names. They configure ordering dependencies between units. If a unit foo.service contains a setting Before=bar.service and both units are being started, bar.service's start-up is delayed until foo.service has finished starting up. Note that this setting is independent of and orthogonal to the requirement dependencies as configured by Requires=, Wants= or BindsTo=. It is a common pattern to include a unit name in both the After= and Requires= options, in which case the unit listed will be started before the unit that is configured with these options. This option may be specified more than once, in which case ordering dependencies for all listed names are created. After= is the inverse of Before=, i.e. while After= ensures that the configured unit is started after the listed unit finished starting up, Before= ensures the opposite, that the configured unit is fully started up before the listed unit is started. Note that when two units with an ordering dependency between them are shut down, the inverse of the start-up order is applied. i.e. if a unit is configured with After= on another unit, the former is stopped before the latter if both are shut down. Given two units with any ordering dependency between them, if one unit is shut down and the other is started up, the shutdown is ordered before the start-up. It doesn't matter if the ordering dependency is After= or Before=, in this case. It also doesn't matter which of the two is shut down, as long as one is shut down and the other is started up. The shutdown is ordered before the start-up in all cases. If two units have no ordering dependencies between them, they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit type when precisely a unit has finished starting up. Most importantly, for service units start-up is considered completed for the purpose of Before=/After= when all its configured start-up commands have been invoked and they either failed or reported start-up success. |
|
list | -- | These two settings ('Before', 'After') expect a space-separated list of unit names. They configure ordering dependencies between units. If a unit foo.service contains a setting Before=bar.service and both units are being started, bar.service's start-up is delayed until foo.service has finished starting up. Note that this setting is independent of and orthogonal to the requirement dependencies as configured by Requires=, Wants= or BindsTo=. It is a common pattern to include a unit name in both the After= and Requires= options, in which case the unit listed will be started before the unit that is configured with these options. This option may be specified more than once, in which case ordering dependencies for all listed names are created. After= is the inverse of Before=, i.e. while After= ensures that the configured unit is started after the listed unit finished starting up, Before= ensures the opposite, that the configured unit is fully started up before the listed unit is started. Note that when two units with an ordering dependency between them are shut down, the inverse of the start-up order is applied. i.e. if a unit is configured with After= on another unit, the former is stopped before the latter if both are shut down. Given two units with any ordering dependency between them, if one unit is shut down and the other is started up, the shutdown is ordered before the start-up. It doesn't matter if the ordering dependency is After= or Before=, in this case. It also doesn't matter which of the two is shut down, as long as one is shut down and the other is started up. The shutdown is ordered before the start-up in all cases. If two units have no ordering dependencies between them, they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit type when precisely a unit has finished starting up. Most importantly, for service units start-up is considered completed for the purpose of Before=/After= when all its configured start-up commands have been invoked and they either failed or reported start-up success. |
|
list | -- | Configures requirement dependencies, very similar in style to Requires=. However, this dependency type is stronger: in addition to the effect of Requires= it declares that if the unit bound to is stopped, this unit will be stopped too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too. Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of a mount unit might be unmounted without involvement of the system and service manager. When used in conjunction with After= on the same unit the behaviour of BindsTo= is even stronger. In this case, the unit bound to strictly has to be in active state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly enters inactive state, but also one that is bound to another unit that gets skipped due to a failed condition check (such as ConditionPathExists=, ConditionPathIsSymbolicLink=, … — see below) will be stopped, should it be running. Hence, in many cases it is best to combine BindsTo= with After=. When BindsTo=b.service is used on a.service, this dependency will show as BoundBy=a.service in property listing of b.service. BoundBy= dependency cannot be specified directly. |
|
list | -- | Before starting a unit, verify that the specified condition is true. If it is not true, the starting of the unit will be (mostly silently) skipped, however all ordering dependencies of it are still respected. A failing condition will not result in the unit being moved into the 'failed' state. The condition is checked at the time the queued start job is to be executed. Use condition expressions in order to silently skip units that do not apply to the local running system, for example because the kernel or runtime environment doesn't require their functionality. Use the various AssertArchitecture=, AssertVirtualization=, … options for a similar mechanism that causes the job to fail (instead of being skipped) and results in logging about the failed check (instead of being silently processed). For details about assertion conditions see the systemd documentation. |
|
list | -- | A space-separated list of unit names. Configures negative requirement dependencies. If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa. Note that this setting is independent of and orthogonal to the After= and Before= ordering dependencies. If a unit A that conflicts with a unit B is scheduled to be started at the same time as B, the transaction will either fail (in case both are required parts of the transaction) or be modified to be fixed (in case one or both jobs are not a required part of the transaction). In the latter case, the job that is not required will be removed, or in case both are not required, the unit that conflicts will be started and the unit that is conflicted is stopped. |
|
string | -- | A human readable name for the unit. This is used by systemd (and other UIs) as the label for the unit, so this string should identify the unit rather than describe it, despite the name. 'Apache2 Web Server' is a good example. Bad examples are 'high-performance light-weight HTTP server' (too generic) or 'Apache2' (too specific and meaningless for people who do not know Apache). systemd will use this string as a noun in status messages ('Starting description...', 'Started description.', 'Reached target description.', 'Failed to start description.'), so it should be capitalized, and should not be a full sentence or a phrase with a continous verb. Bad examples include 'exiting the container' or 'updating the database once per day.'. |
|
['list', 'string'] | -- | A space-separated list of URIs referencing documentation for this unit or its configuration. Accepted are only URIs of the types 'http://', 'https://', 'file:', 'info:', 'man:'. For more information about the syntax of these URIs, see uri(7). The URIs should be listed in order of relevance, starting with the most relevant. It is a good idea to first reference documentation that explains what the unit's purpose is, followed by how it is configured, followed by any other related documentation. This option may be specified more than once, in which case the specified list of URIs is merged. If the empty string is assigned to this option, the list is reset and all prior assignments will have no effect. |
|
list | -- | Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units. When PartOf=b.service is used on a.service, this dependency will show as ConsistsOf=a.service in property listing of b.service. ConsistsOf= dependency cannot be specified directly. |
|
list | -- | Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units fails to activate, and an ordering dependency After= on the failing unit is set, this unit will not be started. Besides, with or without specifying After=, this unit will be stopped if one of the other units is explicitly stopped. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services. Note that this dependency type does not imply that the other unit always has to be in active state when this unit is running. Specifically: failing condition checks (such as ConditionPathExists=, ConditionPathIsSymbolicLink=, … — see below) do not cause the start job of a unit with a Requires= dependency on it to fail. Also, some unit types may deactivate on their own (for example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not propagated to units having a Requires= dependency. Use the BindsTo= dependency type together with After= to ensure that a unit may never be in active state without a specific other unit also in active state (see below). Note that dependencies of this type may also be configured outside of the unit configuration file by adding a symlink to a .requires/ directory accompanying the unit file. For details, see above. |
|
list | -- | Similar to Requires=. However, if the units listed here are not started already, they will not be started and the starting of this unit will fail immediately. Requisite= does not imply an ordering dependency, even if both units are started in the same transaction. Hence this setting should usually be combined with After=, to ensure this unit is not started before the other unit. When Requisite=b.service is used on a.service, this dependency will show as RequisiteOf=a.service in property listing of b.service. RequisiteOf= dependency cannot be specified directly. |
|
integer | -- | Configure unit start rate limiting. Units which are started more than burst times within an interval time interval are not permitted to start any more. Use StartLimitIntervalSec= to configure the checking interval (defaults to DefaultStartLimitIntervalSec= in manager configuration file, set it to 0 to disable any kind of rate limiting). Use StartLimitBurst= to configure how many starts per interval are allowed (defaults to DefaultStartLimitBurst= in manager configuration file). These configuration options are particularly useful in conjunction with the service setting Restart= (see systemd.service(5)); however, they apply to all kinds of starts (including manual), not just those triggered by the Restart= logic. Note that units which are configured for Restart= and which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted manually at a later point, after the interval has passed. From this point on, the restart logic is activated again. Note that systemctl reset-failed will cause the restart rate counter for a service to be flushed, which is useful if the administrator wants to manually start a unit and the start limit interferes with that. Note that this rate-limiting is enforced after any unit condition checks are executed, and hence unit activations with failing conditions do not count towards this rate limit. This setting does not apply to slice, target, device, and scope units, since they are unit types whose activation may either never fail, or may succeed only a single time. |
|
integer | -- | Configure unit start rate limiting. Units which are started more than burst times within an interval time interval are not permitted to start any more. Use StartLimitIntervalSec= to configure the checking interval (defaults to DefaultStartLimitIntervalSec= in manager configuration file, set it to 0 to disable any kind of rate limiting). Use StartLimitBurst= to configure how many starts per interval are allowed (defaults to DefaultStartLimitBurst= in manager configuration file). These configuration options are particularly useful in conjunction with the service setting Restart= (see systemd.service(5)); however, they apply to all kinds of starts (including manual), not just those triggered by the Restart= logic. Note that units which are configured for Restart= and which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted manually at a later point, after the interval has passed. From this point on, the restart logic is activated again. Note that systemctl reset-failed will cause the restart rate counter for a service to be flushed, which is useful if the administrator wants to manually start a unit and the start limit interferes with that. Note that this rate-limiting is enforced after any unit condition checks are executed, and hence unit activations with failing conditions do not count towards this rate limit. This setting does not apply to slice, target, device, and scope units, since they are unit types whose activation may either never fail, or may succeed only a single time. |
|
list | -- | A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole. This is the recommended way to hook start-up of one unit to the start-up of another unit. Note that dependencies of this type may also be configured outside of the unit configuration file by adding symlinks to a .wants/ directory accompanying the unit file. For details, see above. |
Examples
Example 1
Create a systemd-unit file for the 'keycloak' service.
Code
- systemd-service-unit: name: keycloak desc: keycloak authentication service service_config: - KEYCLOAK_CONFIG: standalone.xml KEYCLOAK_MODE: standalone KEYCLOAK_BIND: 127.0.0.1 ServiceType: idle ServiceEnvironment: LAUNCH_JBOSS_IN_BACKGROUND=1 ServiceUser: keycloak ServiceGroup: keycloak ExecStart: /usr/local/bin/keycloak-launch.sh ${KEYCLOAK_MODE} ${KEYCLOAK_CONFIG} ${KEYCLOAK_BIND} UnitBefore: - httpd.service UnitAfter: - network.target ServiceTimeoutStartSec: 600 ServiceTimeoutStopSec: 600 InstallWantedBy: - multi-user.target enabled: true started: true
Code
doc: short_help: Create and configure a certain systemd service unit exists. help: | Add a systemd unit for a service. This does not create the user from the 'service_user' parameter, nor the group from 'service_group'. examples: - title: Create a systemd-unit file for the 'keycloak' service. vars: name: keycloak desc: keycloak authentication service service_config: - KEYCLOAK_CONFIG: standalone.xml KEYCLOAK_MODE: standalone KEYCLOAK_BIND: 127.0.0.1 ServiceType: idle ServiceEnvironment: LAUNCH_JBOSS_IN_BACKGROUND=1 ServiceUser: keycloak ServiceGroup: keycloak ExecStart: /usr/local/bin/keycloak-launch.sh ${KEYCLOAK_MODE} ${KEYCLOAK_CONFIG} ${KEYCLOAK_BIND} UnitBefore: - httpd.service UnitAfter: - network.target ServiceTimeoutStartSec: 600 ServiceTimeoutStopSec: 600 InstallWantedBy: - multi-user.target enabled: true started: true args: _import: systemd-service-unit-file name: doc: short_help: The name of the service. required: true type: string cli: metavar: SERVICE_NAME enabled: doc: short_help: Whether to enable the service. type: boolean required: false cli: is_flag: true show_default: true started: doc: short_help: Whether to start the service. type: boolean required: false cli: is_flag: true show_default: true service_config: doc: short_help: A map of key/value-pairs to put into a '/etc/conf.d/<service>' file. help: | A map of key/value-pairs to put into a '/etc/conf.d/<service>' file. This can be used in addition or instead of 'service_environment' and 'service_environment_file'. It is meant as a short-cut, to not have to create the config file (in '/etc/conf.d') in an extra step. type: dict keyschema: type: string default: {} required: false empty: true is_template_unit: doc: short_help: Whether this unit is a 'template unit' (can be parametrized and instance name ends with '@'). references: systemd unit documentation: https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description type: boolean required: false default: false cli: param_decls: - --is-template-unit instance_name: doc: short_help: The instance name, in case this unit is enabled or started, and the 'is_template_unit' flag is set. type: string required: false meta: tags: - systemd - systemd-unit - service frecklets: - systemd-service-config: frecklet::skip: '{{:: service_config | true_if_empty ::}}' service_name: '{{:: name ::}}' env_vars: '{{:: service_config ::}}' - systemd-service-unit-file: frecklet::desc: short: "create systemd unit for service '{{:: name ::}}'" long: | "Create a systemd unit for service '{{:": name ::}}' as per provided variables. # TODO: list variables path: '/etc/systemd/system/{{:: name ::}}{%:: if is_template_unit ::%}@{%:: endif ::%}.service' owner: root group: root mode: '0644' unit_description: '{{:: unit_description ::}}' unit_documentation: '{{:: unit_documentation ::}}' unit_requires: '{{:: unit_requires ::}}' unit_requisite: '{{:: unit_requisite ::}}' unit_wants: '{{:: unit_wants ::}}' unit_binds_to: '{{:: unit_binds_to ::}}' unit_part_of: '{{:: unit_part_of ::}}' unit_conflicts: '{{:: unit_conflicts ::}}' unit_before: '{{:: unit_before ::}}' unit_after: '{{:: unit_after ::}}' unit_condition: '{{:: unit_condition ::}}' unit_start_limit_burst: '{{:: unit_start_limit_burst ::}}' unit_start_limit_interval_sec: '{{:: unit_start_limit_interval_sec ::}}' install_alias: '{{:: install_alias ::}}' install_wanted_by: '{{:: install_wanted_by ::}}' install_required_by: '{{:: install_required_by ::}}' install_also: '{{:: install_also ::}}' install_default_instance: '{{:: install_default_instance ::}}' service_type: '{{:: service_type ::}}' service_remain_after_exit: '{{:: service_remain_after_exit ::}}' service_guess_main_pid: '{{:: service_guess_main_pid ::}}' service_pid_file: '{{:: service_pid_file ::}}' service_bus_name: '{{:: service_bus_name ::}}' service_environment: '{{:: service_environment ::}}' service_environment_file: '{{:: service_environment_file ::}}' service_environment_file_extra: '{%:: if service_config is defined and service_config ::%}/etc/conf.d/{{:: name ::}}{%:: endif ::%}' service_user: '{{:: service_user ::}}' service_group: '{{:: service_group ::}}' service_exec_start: '{{:: service_exec_start ::}}' service_exec_start_pre: '{{:: service_exec_start_pre ::}}' service_exec_start_post: '{{:: service_exec_start_post ::}}' service_timeout_start_sec: '{{:: service_timeout_start_sec ::}}' service_timeout_stop_sec: '{{:: service_timeout_stop_sec ::}}' service_timeout_sec: '{{:: service_timeout_sec ::}}' service_working_directory: '{{:: service_working_directory ::}}' service_restart: '{{:: service_restart ::}}' service_restart_sec: '{{:: service_restart_sec ::}}' service_exec_reload: '{{:: service_exec_reload ::}}' service_exec_stop: '{{:: service_exec_stop ::}}' service_exec_stop_post: '{{:: service_exec_stop_post ::}}' service_kill_mode: '{{:: service_kill_mode ::}}' service_kill_signal: '{{:: service_kill_signal ::}}' service_tasks_max: '{{:: service_tasks_max ::}}' service_private_tmp: '{{:: service_private_tmp ::}}' service_permissions_start_only: '{{:: service_permissions_start_only ::}}' service_limit: '{{:: service_limit ::}}' service_protect_system: '{{:: service_protect_system ::}}' service_protect_home: '{{:: service_protect_home ::}}' service_private_devices: '{{:: service_private_devices ::}}' service_secure_bits: '{{:: service_secure_bits ::}}' service_ambient_capabilities: '{{:: service_ambient_capabilities ::}}' service_capability_bounding_set: '{{:: service_capability_bounding_set ::}}' service_no_new_privileges: '{{:: service_no_new_privileges ::}}' service_runtime_directory: '{{:: service_runtime_directory ::}}' service_runtime_directory_mode: '{{:: service_runtime_directory_mode ::}}' service_success_exit_status: '{{:: service_success_exit_status ::}}' service_restart_force_exit_status: '{{:: service_restart_force_exit_status ::}}' service_system_call_architectures: '{{:: service_system_call_architectures ::}}' service_memory_deny_write_execute: '{{:: service_memory_deny_write_execute ::}}' service_delegate: '{{:: service_delegate ::}}' - init-service-configured: frecklet::skip: '{{:: enabled is not defined and started is not defined ::}}' name: '{{:: name ::}}' instance_name: '{{:: instance_name ::}}' enabled: '{{:: enabled ::}}' started: '{{:: started ::}}'
frecklecute systemd-service-unit --help Usage: frecklecute systemd-service-unit [OPTIONS] Add a systemd unit for a service. This does not create the user from the 'service_user' parameter, nor the group from 'service_group'. Options: --name SERVICE_NAME The name of the service. [required] --service-exec-start SERVICE_EXEC_START Commands with their arguments that are executed when this service is started. [required] --enabled / --no-enabled Whether to enable the service. --install-alias INSTALL_ALIAS A space-separated list of additional names this unit shall be installed under. --install-also INSTALL_ALSO Additional units to install/deinstall when this unit is installed/deinstalled. --install-default-instance INSTALL_DEFAULT_INSTANCE In template unit files, this specifies for which instance the unit shall be enabled if the template is enabled without any explicitly set instance. --install-required-by INSTALL_REQUIRED_BY This option may be used more than once, or a space-separated list of unit names may be given. --install-wanted-by INSTALL_WANTED_BY This option may be used more than once, or a space-separated list of unit names may be given. --instance-name INSTANCE_NAME The instance name, in case this unit is enabled or started, and the 'is_template_unit' flag is set. --is-template-unit Whether this unit is a 'template unit' (can be parametrized and instance name ends with '@'). --service-ambient-capabilities SERVICE_AMBIENT_CAPABILITIES Controls which capabilities to include in the ambient capability set for the executed process. --service-bus-name SERVICE_BUS_NAME Takes a D-Bus bus name that this service is reachable as. This option is mandatory for services where Type= is set to dbus. --service-capability-bounding-set SERVICE_CAPABILITY_BOUNDING_SET Controls which capabilities to include in the capability bounding set for the executed process. --service-config SERVICE_CONFIG A map of key/value-pairs to put into a '/etc/conf.d/<service>' file. --service-delegate / --no-service-delegate Turns on delegation of further resource control partitioning to processes of the unit. --service-environment SERVICE_ENVIRONMENT Sets environment variables for executed processes. --service-environment-file SERVICE_ENVIRONMENT_FILE Similar to Environment= but reads the environment variables from a text file. --service-exec-reload SERVICE_EXEC_RELOAD Commands to execute to trigger a configuration reload in the service. --service-exec-start-post SERVICE_EXEC_START_POST Additional commands that are executed before or after the command in ExecStart=, respectively. --service-exec-start-pre SERVICE_EXEC_START_PRE Additional commands that are executed before or after the command in ExecStart=, respectively. --service-exec-stop SERVICE_EXEC_STOP Commands to execute to stop the service started via ExecStart=. --service-exec-stop-post SERVICE_EXEC_STOP_POST Additional commands that are executed after the service is stopped. --service-group SERVICE_GROUP Set the UNIX user or group that the processes are executed as, respectively. --service-guess-main-pid / --no-service-guess-main-pid Takes a boolean value that specifies whether systemd should try to guess the main PID of a service if it cannot be determined reliably. --service-kill-mode SERVICE_KILL_MODE Specifies how processes of this unit shall be killed. One of control-group, process, mixed, none. --service-kill-signal SERVICE_KILL_SIGNAL Specifies which signal to use when killing a service. --service-limit SERVICE_LIMIT Set soft and hard limits on various resources for executed processes. --service-memory-deny-write-execute / --no-service-memory-deny-write-execute If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable are prohibited --service-no-new-privileges / --no-service-no-new-privileges Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). --service-permissions-start-only / --no-service-permissions-start-only Takes a boolean argument. If true, the permission-related execution options, as configured with User= and similar options (see systemd.exec(5) for more information), are only applied to the process started with ExecStart=, and not to the various other ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, and ExecStopPost= commands. If false, the setting is applied to all configured commands the same way. Defaults to false. --service-pid-file SERVICE_PID_FILE Takes a path referring to the PID file of the service. --service-private-devices / --no-service-private-devices Takes a boolean argument. If true, sets up a new /dev mount for the executed processes and only adds API pseudo devices such as /dev/null, /dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it, but no physical devices such as /dev/sda, system memory /dev/mem, system ports /dev/port and others. --service-private-tmp / --no-service-private-tmp If true, sets up a new file system namespace for the executed processes and mounts private /tmp and /var/tmp directories inside it that is not shared by processes outside of the namespace. --service-protect-home SERVICE_PROTECT_HOME Takes a boolean argument or the special values 'read-only' or 'tmpfs'. --service-protect-system SERVICE_PROTECT_SYSTEM Takes a boolean argument or the special values 'full' or 'strict'. --service-remain-after-exit / --no-service-remain-after-exit Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. Defaults to no. --service-restart SERVICE_RESTART Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. --service-restart-force-exit-status SERVICE_RESTART_FORCE_EXIT_STATUS a list of exit status definitions that, when returned by the main service process, will force automatic service restarts, regardless of the restart setting configured with Restart=. --service-restart-sec SERVICE_RESTART_SEC Configures the time to sleep before restarting a service (as configured with Restart=). --service-runtime-directory SERVICE_RUNTIME_DIRECTORY Create a runtime directory for a service. --service-runtime-directory-mode SERVICE_RUNTIME_DIRECTORY_MODE Sets the permission for the 'service_runtime_directory' values. --service-secure-bits SERVICE_SECURE_BITS Controls the secure bits set for the executed process. --service-success-exit-status SERVICE_SUCCESS_EXIT_STATUS Takes a list of exit status definitions that, when returned by the main service process, will be considered successful termination, in addition to the normal successful exit code 0 and the signals SIGHUP, SIGINT, SIGTERM, and SIGPIPE. --service-system-call-architectures SERVICE_SYSTEM_CALL_ARCHITECTURES Takes a space-separated list of architecture identifiers. Selects from which architectures system calls may be invoked on this system. --service-tasks-max SERVICE_TASKS_MAX Specify the maximum number of tasks that may be created in the unit. --service-timeout-sec SERVICE_TIMEOUT_SEC A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified value. --service-timeout-start-sec SERVICE_TIMEOUT_START_SEC Configures the time to wait for start-up. --service-timeout-stop-sec SERVICE_TIMEOUT_STOP_SEC Configures the time to wait for each ExecStop= command and the time to wait for the service itself to stop. --service-type SERVICE_TYPE Configures the process start-up type for this service unit. --service-user SERVICE_USER Set the UNIX user or group that the processes are executed as, respectively. --service-working-directory SERVICE_WORKING_DIRECTORY Takes a directory path relative to the service's root directory specified by RootDirectory=, or the special value '~'. --started / --no-started Whether to start the service. --unit-after UNIT_AFTER These two settings ('Before', 'After') expect a space-separated list of unit names. They configure ordering dependencies between units. --unit-before UNIT_BEFORE These two settings ('Before', 'After') expect a space-separated list of unit names. They configure ordering dependencies between units. --unit-binds-to UNIT_BINDS_TO Configures requirement dependencies, very similar in style to Requires=. --unit-condition UNIT_CONDITION Before starting a unit, verify that the specified condition is true. --unit-conflicts UNIT_CONFLICTS A space-separated list of unit names. Configures negative requirement dependencies. --unit-description UNIT_DESCRIPTION A human readable name for the unit. --unit-documentation UNIT_DOCUMENTATION A space-separated list of URIs referencing documentation for this unit or its configuration. --unit-part-of UNIT_PART_OF Configures dependencies similar to Requires=, but limited to stopping and restarting of units. --unit-requires UNIT_REQUIRES Configures requirement dependencies on other units. --unit-requisite UNIT_REQUISITE Similar to Requires=. However, if the units listed here are not started already, they will not be started and the starting of this unit will fail immediately. --unit-start-limit-burst UNIT_START_LIMIT_BURST Configure unit start rate limiting. --unit-start-limit-interval-sec UNIT_START_LIMIT_INTERVAL_SEC Configure unit start rate limiting. --unit-wants UNIT_WANTS A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. --help Show this message and exit.
# -*- coding: utf-8 -*- # # module path: pycklets.systemd_service_unit.SystemdServiceUnit # from dataclasses import dataclass from pyckles import AutoPycklet from typing import * # noqa @dataclass class SystemdServiceUnit(AutoPycklet): """Add a systemd unit for a service. This does not create the user from the 'service_user' parameter, nor the group from 'service_group'. Args: enabled: Whether to enable the service. install_alias: A space-separated list of additional names this unit shall be installed under. install_also: Additional units to install/deinstall when this unit is installed/deinstalled. install_default_instance: In template unit files, this specifies for which instance the unit shall be enabled if the template is enabled without any explicitly set instance. install_required_by: This option may be used more than once, or a space-separated list of unit names may be given. install_wanted_by: This option may be used more than once, or a space-separated list of unit names may be given. instance_name: The instance name, in case this unit is enabled or started, and the 'is_template_unit' flag is set. is_template_unit: Whether this unit is a 'template unit' (can be parametrized and instance name ends with '@'). name: The name of the service. service_ambient_capabilities: Controls which capabilities to include in the ambient capability set for the executed process. service_bus_name: Takes a D-Bus bus name that this service is reachable as. This option is mandatory for services where Type= is set to dbus. service_capability_bounding_set: Controls which capabilities to include in the capability bounding set for the executed process. service_config: A map of key/value-pairs to put into a '/etc/conf.d/<service>' file. service_delegate: Turns on delegation of further resource control partitioning to processes of the unit. service_environment: Sets environment variables for executed processes. service_environment_file: Similar to Environment= but reads the environment variables from a text file. service_exec_reload: Commands to execute to trigger a configuration reload in the service. service_exec_start: Commands with their arguments that are executed when this service is started. service_exec_start_post: Additional commands that are executed before or after the command in ExecStart=, respectively. service_exec_start_pre: Additional commands that are executed before or after the command in ExecStart=, respectively. service_exec_stop: Commands to execute to stop the service started via ExecStart=. service_exec_stop_post: Additional commands that are executed after the service is stopped. service_group: Set the UNIX user or group that the processes are executed as, respectively. service_guess_main_pid: Takes a boolean value that specifies whether systemd should try to guess the main PID of a service if it cannot be determined reliably. service_kill_mode: Specifies how processes of this unit shall be killed. One of control-group, process, mixed, none. service_kill_signal: Specifies which signal to use when killing a service. service_limit: Set soft and hard limits on various resources for executed processes. service_memory_deny_write_execute: If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable are prohibited service_no_new_privileges: Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). service_permissions_start_only: Takes a boolean argument. If true, the permission-related execution options, as configured with User= and similar options (see systemd.exec(5) for more information), are only applied to the process started with ExecStart=, and not to the various other ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, and ExecStopPost= commands. If false, the setting is applied to all configured commands the same way. Defaults to false. service_pid_file: Takes a path referring to the PID file of the service. service_private_devices: Takes a boolean argument. If true, sets up a new /dev mount for the executed processes and only adds API pseudo devices such as /dev/null, /dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it, but no physical devices such as /dev/sda, system memory /dev/mem, system ports /dev/port and others. service_private_tmp: If true, sets up a new file system namespace for the executed processes and mounts private /tmp and /var/tmp directories inside it that is not shared by processes outside of the namespace. service_protect_home: Takes a boolean argument or the special values 'read-only' or 'tmpfs'. service_protect_system: Takes a boolean argument or the special values 'full' or 'strict'. service_remain_after_exit: Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. Defaults to no. service_restart: Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. service_restart_force_exit_status: a list of exit status definitions that, when returned by the main service process, will force automatic service restarts, regardless of the restart setting configured with Restart=. service_restart_sec: Configures the time to sleep before restarting a service (as configured with Restart=). service_runtime_directory: Create a runtime directory for a service. service_runtime_directory_mode: Sets the permission for the 'service_runtime_directory' values. service_secure_bits: Controls the secure bits set for the executed process. service_success_exit_status: Takes a list of exit status definitions that, when returned by the main service process, will be considered successful termination, in addition to the normal successful exit code 0 and the signals SIGHUP, SIGINT, SIGTERM, and SIGPIPE. service_system_call_architectures: Takes a space-separated list of architecture identifiers. Selects from which architectures system calls may be invoked on this system. service_tasks_max: Specify the maximum number of tasks that may be created in the unit. service_timeout_sec: A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified value. service_timeout_start_sec: Configures the time to wait for start-up. service_timeout_stop_sec: Configures the time to wait for each ExecStop= command and the time to wait for the service itself to stop. service_type: Configures the process start-up type for this service unit. service_user: Set the UNIX user or group that the processes are executed as, respectively. service_working_directory: Takes a directory path relative to the service's root directory specified by RootDirectory=, or the special value '~'. started: Whether to start the service. unit_after: These two settings ('Before', 'After') expect a space-separated list of unit names. They configure ordering dependencies between units. unit_before: These two settings ('Before', 'After') expect a space-separated list of unit names. They configure ordering dependencies between units. unit_binds_to: Configures requirement dependencies, very similar in style to Requires=. unit_condition: Before starting a unit, verify that the specified condition is true. unit_conflicts: A space-separated list of unit names. Configures negative requirement dependencies. unit_description: A human readable name for the unit. unit_documentation: A space-separated list of URIs referencing documentation for this unit or its configuration. unit_part_of: Configures dependencies similar to Requires=, but limited to stopping and restarting of units. unit_requires: Configures requirement dependencies on other units. unit_requisite: Similar to Requires=. However, if the units listed here are not started already, they will not be started and the starting of this unit will fail immediately. unit_start_limit_burst: Configure unit start rate limiting. unit_start_limit_interval_sec: Configure unit start rate limiting. unit_wants: A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. """ FRECKLET_ID = "systemd-service-unit" enabled: bool = None install_alias: List = None install_also: List = None install_default_instance: str = None install_required_by: List = None install_wanted_by: List = None instance_name: str = None is_template_unit: bool = None name: str = None service_ambient_capabilities: List = None service_bus_name: str = None service_capability_bounding_set: List = None service_config: Dict = None service_delegate: bool = None service_environment: Dict = None service_environment_file: Any = None service_exec_reload: Any = None service_exec_start: Any = None service_exec_start_post: Any = None service_exec_start_pre: Any = None service_exec_stop: Any = None service_exec_stop_post: Any = None service_group: str = None service_guess_main_pid: bool = None service_kill_mode: str = None service_kill_signal: str = None service_limit: List = None service_memory_deny_write_execute: bool = None service_no_new_privileges: bool = None service_permissions_start_only: bool = None service_pid_file: str = None service_private_devices: bool = None service_private_tmp: bool = None service_protect_home: str = None service_protect_system: str = None service_remain_after_exit: bool = None service_restart: str = None service_restart_force_exit_status: List = None service_restart_sec: int = None service_runtime_directory: List = None service_runtime_directory_mode: str = None service_secure_bits: List = None service_success_exit_status: List = None service_system_call_architectures: List = None service_tasks_max: str = None service_timeout_sec: int = None service_timeout_start_sec: int = None service_timeout_stop_sec: int = None service_type: str = None service_user: str = None service_working_directory: str = None started: bool = None unit_after: List = None unit_before: List = None unit_binds_to: List = None unit_condition: List = None unit_conflicts: List = None unit_description: str = None unit_documentation: Any = None unit_part_of: List = None unit_requires: List = None unit_requisite: List = None unit_start_limit_burst: int = None unit_start_limit_interval_sec: int = None unit_wants: List = None def __post_init__(self): super(SystemdServiceUnit, self).__init__(var_names=["enabled", "install_alias", "install_also", "install_default_instance", "install_required_by", "install_wanted_by", "instance_name", "is_template_unit", "name", "service_ambient_capabilities", "service_bus_name", "service_capability_bounding_set", "service_config", "service_delegate", "service_environment", "service_environment_file", "service_exec_reload", "service_exec_start", "service_exec_start_post", "service_exec_start_pre", "service_exec_stop", "service_exec_stop_post", "service_group", "service_guess_main_pid", "service_kill_mode", "service_kill_signal", "service_limit", "service_memory_deny_write_execute", "service_no_new_privileges", "service_permissions_start_only", "service_pid_file", "service_private_devices", "service_private_tmp", "service_protect_home", "service_protect_system", "service_remain_after_exit", "service_restart", "service_restart_force_exit_status", "service_restart_sec", "service_runtime_directory", "service_runtime_directory_mode", "service_secure_bits", "service_success_exit_status", "service_system_call_architectures", "service_tasks_max", "service_timeout_sec", "service_timeout_start_sec", "service_timeout_stop_sec", "service_type", "service_user", "service_working_directory", "started", "unit_after", "unit_before", "unit_binds_to", "unit_condition", "unit_conflicts", "unit_description", "unit_documentation", "unit_part_of", "unit_requires", "unit_requisite", "unit_start_limit_burst", "unit_start_limit_interval_sec", "unit_wants"]) frecklet_class = SystemdServiceUnit
# -*- coding: utf-8 -*- # # module path: pycklets.systemd_service_unit.SystemdServiceUnit # from pyckles import AutoPycklet class SystemdServiceUnit(AutoPycklet): """Add a systemd unit for a service. This does not create the user from the 'service_user' parameter, nor the group from 'service_group'. Args: enabled: Whether to enable the service. install_alias: A space-separated list of additional names this unit shall be installed under. install_also: Additional units to install/deinstall when this unit is installed/deinstalled. install_default_instance: In template unit files, this specifies for which instance the unit shall be enabled if the template is enabled without any explicitly set instance. install_required_by: This option may be used more than once, or a space-separated list of unit names may be given. install_wanted_by: This option may be used more than once, or a space-separated list of unit names may be given. instance_name: The instance name, in case this unit is enabled or started, and the 'is_template_unit' flag is set. is_template_unit: Whether this unit is a 'template unit' (can be parametrized and instance name ends with '@'). name: The name of the service. service_ambient_capabilities: Controls which capabilities to include in the ambient capability set for the executed process. service_bus_name: Takes a D-Bus bus name that this service is reachable as. This option is mandatory for services where Type= is set to dbus. service_capability_bounding_set: Controls which capabilities to include in the capability bounding set for the executed process. service_config: A map of key/value-pairs to put into a '/etc/conf.d/<service>' file. service_delegate: Turns on delegation of further resource control partitioning to processes of the unit. service_environment: Sets environment variables for executed processes. service_environment_file: Similar to Environment= but reads the environment variables from a text file. service_exec_reload: Commands to execute to trigger a configuration reload in the service. service_exec_start: Commands with their arguments that are executed when this service is started. service_exec_start_post: Additional commands that are executed before or after the command in ExecStart=, respectively. service_exec_start_pre: Additional commands that are executed before or after the command in ExecStart=, respectively. service_exec_stop: Commands to execute to stop the service started via ExecStart=. service_exec_stop_post: Additional commands that are executed after the service is stopped. service_group: Set the UNIX user or group that the processes are executed as, respectively. service_guess_main_pid: Takes a boolean value that specifies whether systemd should try to guess the main PID of a service if it cannot be determined reliably. service_kill_mode: Specifies how processes of this unit shall be killed. One of control-group, process, mixed, none. service_kill_signal: Specifies which signal to use when killing a service. service_limit: Set soft and hard limits on various resources for executed processes. service_memory_deny_write_execute: If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable are prohibited service_no_new_privileges: Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). service_permissions_start_only: Takes a boolean argument. If true, the permission-related execution options, as configured with User= and similar options (see systemd.exec(5) for more information), are only applied to the process started with ExecStart=, and not to the various other ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, and ExecStopPost= commands. If false, the setting is applied to all configured commands the same way. Defaults to false. service_pid_file: Takes a path referring to the PID file of the service. service_private_devices: Takes a boolean argument. If true, sets up a new /dev mount for the executed processes and only adds API pseudo devices such as /dev/null, /dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it, but no physical devices such as /dev/sda, system memory /dev/mem, system ports /dev/port and others. service_private_tmp: If true, sets up a new file system namespace for the executed processes and mounts private /tmp and /var/tmp directories inside it that is not shared by processes outside of the namespace. service_protect_home: Takes a boolean argument or the special values 'read-only' or 'tmpfs'. service_protect_system: Takes a boolean argument or the special values 'full' or 'strict'. service_remain_after_exit: Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. Defaults to no. service_restart: Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. service_restart_force_exit_status: a list of exit status definitions that, when returned by the main service process, will force automatic service restarts, regardless of the restart setting configured with Restart=. service_restart_sec: Configures the time to sleep before restarting a service (as configured with Restart=). service_runtime_directory: Create a runtime directory for a service. service_runtime_directory_mode: Sets the permission for the 'service_runtime_directory' values. service_secure_bits: Controls the secure bits set for the executed process. service_success_exit_status: Takes a list of exit status definitions that, when returned by the main service process, will be considered successful termination, in addition to the normal successful exit code 0 and the signals SIGHUP, SIGINT, SIGTERM, and SIGPIPE. service_system_call_architectures: Takes a space-separated list of architecture identifiers. Selects from which architectures system calls may be invoked on this system. service_tasks_max: Specify the maximum number of tasks that may be created in the unit. service_timeout_sec: A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified value. service_timeout_start_sec: Configures the time to wait for start-up. service_timeout_stop_sec: Configures the time to wait for each ExecStop= command and the time to wait for the service itself to stop. service_type: Configures the process start-up type for this service unit. service_user: Set the UNIX user or group that the processes are executed as, respectively. service_working_directory: Takes a directory path relative to the service's root directory specified by RootDirectory=, or the special value '~'. started: Whether to start the service. unit_after: These two settings ('Before', 'After') expect a space-separated list of unit names. They configure ordering dependencies between units. unit_before: These two settings ('Before', 'After') expect a space-separated list of unit names. They configure ordering dependencies between units. unit_binds_to: Configures requirement dependencies, very similar in style to Requires=. unit_condition: Before starting a unit, verify that the specified condition is true. unit_conflicts: A space-separated list of unit names. Configures negative requirement dependencies. unit_description: A human readable name for the unit. unit_documentation: A space-separated list of URIs referencing documentation for this unit or its configuration. unit_part_of: Configures dependencies similar to Requires=, but limited to stopping and restarting of units. unit_requires: Configures requirement dependencies on other units. unit_requisite: Similar to Requires=. However, if the units listed here are not started already, they will not be started and the starting of this unit will fail immediately. unit_start_limit_burst: Configure unit start rate limiting. unit_start_limit_interval_sec: Configure unit start rate limiting. unit_wants: A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. """ FRECKLET_ID = "systemd-service-unit" def __init__(self, enabled=None, install_alias=None, install_also=None, install_default_instance=None, install_required_by=None, install_wanted_by=None, instance_name=None, is_template_unit=None, name=None, service_ambient_capabilities=None, service_bus_name=None, service_capability_bounding_set=None, service_config=None, service_delegate=None, service_environment=None, service_environment_file=None, service_exec_reload=None, service_exec_start=None, service_exec_start_post=None, service_exec_start_pre=None, service_exec_stop=None, service_exec_stop_post=None, service_group=None, service_guess_main_pid=None, service_kill_mode=None, service_kill_signal=None, service_limit=None, service_memory_deny_write_execute=None, service_no_new_privileges=None, service_permissions_start_only=None, service_pid_file=None, service_private_devices=None, service_private_tmp=None, service_protect_home=None, service_protect_system=None, service_remain_after_exit=None, service_restart=None, service_restart_force_exit_status=None, service_restart_sec=None, service_runtime_directory=None, service_runtime_directory_mode=None, service_secure_bits=None, service_success_exit_status=None, service_system_call_architectures=None, service_tasks_max=None, service_timeout_sec=None, service_timeout_start_sec=None, service_timeout_stop_sec=None, service_type="simple", service_user=None, service_working_directory=None, started=None, unit_after=None, unit_before=None, unit_binds_to=None, unit_condition=None, unit_conflicts=None, unit_description=None, unit_documentation=None, unit_part_of=None, unit_requires=None, unit_requisite=None, unit_start_limit_burst=None, unit_start_limit_interval_sec=None, unit_wants=None): super(SystemdServiceUnit, self).__init__(var_names=["enabled", "install_alias", "install_also", "install_default_instance", "install_required_by", "install_wanted_by", "instance_name", "is_template_unit", "name", "service_ambient_capabilities", "service_bus_name", "service_capability_bounding_set", "service_config", "service_delegate", "service_environment", "service_environment_file", "service_exec_reload", "service_exec_start", "service_exec_start_post", "service_exec_start_pre", "service_exec_stop", "service_exec_stop_post", "service_group", "service_guess_main_pid", "service_kill_mode", "service_kill_signal", "service_limit", "service_memory_deny_write_execute", "service_no_new_privileges", "service_permissions_start_only", "service_pid_file", "service_private_devices", "service_private_tmp", "service_protect_home", "service_protect_system", "service_remain_after_exit", "service_restart", "service_restart_force_exit_status", "service_restart_sec", "service_runtime_directory", "service_runtime_directory_mode", "service_secure_bits", "service_success_exit_status", "service_system_call_architectures", "service_tasks_max", "service_timeout_sec", "service_timeout_start_sec", "service_timeout_stop_sec", "service_type", "service_user", "service_working_directory", "started", "unit_after", "unit_before", "unit_binds_to", "unit_condition", "unit_conflicts", "unit_description", "unit_documentation", "unit_part_of", "unit_requires", "unit_requisite", "unit_start_limit_burst", "unit_start_limit_interval_sec", "unit_wants"]) self._enabled = enabled self._install_alias = install_alias self._install_also = install_also self._install_default_instance = install_default_instance self._install_required_by = install_required_by self._install_wanted_by = install_wanted_by self._instance_name = instance_name self._is_template_unit = is_template_unit self._name = name self._service_ambient_capabilities = service_ambient_capabilities self._service_bus_name = service_bus_name self._service_capability_bounding_set = service_capability_bounding_set self._service_config = service_config self._service_delegate = service_delegate self._service_environment = service_environment self._service_environment_file = service_environment_file self._service_exec_reload = service_exec_reload self._service_exec_start = service_exec_start self._service_exec_start_post = service_exec_start_post self._service_exec_start_pre = service_exec_start_pre self._service_exec_stop = service_exec_stop self._service_exec_stop_post = service_exec_stop_post self._service_group = service_group self._service_guess_main_pid = service_guess_main_pid self._service_kill_mode = service_kill_mode self._service_kill_signal = service_kill_signal self._service_limit = service_limit self._service_memory_deny_write_execute = service_memory_deny_write_execute self._service_no_new_privileges = service_no_new_privileges self._service_permissions_start_only = service_permissions_start_only self._service_pid_file = service_pid_file self._service_private_devices = service_private_devices self._service_private_tmp = service_private_tmp self._service_protect_home = service_protect_home self._service_protect_system = service_protect_system self._service_remain_after_exit = service_remain_after_exit self._service_restart = service_restart self._service_restart_force_exit_status = service_restart_force_exit_status self._service_restart_sec = service_restart_sec self._service_runtime_directory = service_runtime_directory self._service_runtime_directory_mode = service_runtime_directory_mode self._service_secure_bits = service_secure_bits self._service_success_exit_status = service_success_exit_status self._service_system_call_architectures = service_system_call_architectures self._service_tasks_max = service_tasks_max self._service_timeout_sec = service_timeout_sec self._service_timeout_start_sec = service_timeout_start_sec self._service_timeout_stop_sec = service_timeout_stop_sec self._service_type = service_type self._service_user = service_user self._service_working_directory = service_working_directory self._started = started self._unit_after = unit_after self._unit_before = unit_before self._unit_binds_to = unit_binds_to self._unit_condition = unit_condition self._unit_conflicts = unit_conflicts self._unit_description = unit_description self._unit_documentation = unit_documentation self._unit_part_of = unit_part_of self._unit_requires = unit_requires self._unit_requisite = unit_requisite self._unit_start_limit_burst = unit_start_limit_burst self._unit_start_limit_interval_sec = unit_start_limit_interval_sec self._unit_wants = unit_wants @property def enabled(self): return self._enabled @enabled.setter def enabled(self, enabled): self._enabled = enabled @property def install_alias(self): return self._install_alias @install_alias.setter def install_alias(self, install_alias): self._install_alias = install_alias @property def install_also(self): return self._install_also @install_also.setter def install_also(self, install_also): self._install_also = install_also @property def install_default_instance(self): return self._install_default_instance @install_default_instance.setter def install_default_instance(self, install_default_instance): self._install_default_instance = install_default_instance @property def install_required_by(self): return self._install_required_by @install_required_by.setter def install_required_by(self, install_required_by): self._install_required_by = install_required_by @property def install_wanted_by(self): return self._install_wanted_by @install_wanted_by.setter def install_wanted_by(self, install_wanted_by): self._install_wanted_by = install_wanted_by @property def instance_name(self): return self._instance_name @instance_name.setter def instance_name(self, instance_name): self._instance_name = instance_name @property def is_template_unit(self): return self._is_template_unit @is_template_unit.setter def is_template_unit(self, is_template_unit): self._is_template_unit = is_template_unit @property def name(self): return self._name @name.setter def name(self, name): self._name = name @property def service_ambient_capabilities(self): return self._service_ambient_capabilities @service_ambient_capabilities.setter def service_ambient_capabilities(self, service_ambient_capabilities): self._service_ambient_capabilities = service_ambient_capabilities @property def service_bus_name(self): return self._service_bus_name @service_bus_name.setter def service_bus_name(self, service_bus_name): self._service_bus_name = service_bus_name @property def service_capability_bounding_set(self): return self._service_capability_bounding_set @service_capability_bounding_set.setter def service_capability_bounding_set(self, service_capability_bounding_set): self._service_capability_bounding_set = service_capability_bounding_set @property def service_config(self): return self._service_config @service_config.setter def service_config(self, service_config): self._service_config = service_config @property def service_delegate(self): return self._service_delegate @service_delegate.setter def service_delegate(self, service_delegate): self._service_delegate = service_delegate @property def service_environment(self): return self._service_environment @service_environment.setter def service_environment(self, service_environment): self._service_environment = service_environment @property def service_environment_file(self): return self._service_environment_file @service_environment_file.setter def service_environment_file(self, service_environment_file): self._service_environment_file = service_environment_file @property def service_exec_reload(self): return self._service_exec_reload @service_exec_reload.setter def service_exec_reload(self, service_exec_reload): self._service_exec_reload = service_exec_reload @property def service_exec_start(self): return self._service_exec_start @service_exec_start.setter def service_exec_start(self, service_exec_start): self._service_exec_start = service_exec_start @property def service_exec_start_post(self): return self._service_exec_start_post @service_exec_start_post.setter def service_exec_start_post(self, service_exec_start_post): self._service_exec_start_post = service_exec_start_post @property def service_exec_start_pre(self): return self._service_exec_start_pre @service_exec_start_pre.setter def service_exec_start_pre(self, service_exec_start_pre): self._service_exec_start_pre = service_exec_start_pre @property def service_exec_stop(self): return self._service_exec_stop @service_exec_stop.setter def service_exec_stop(self, service_exec_stop): self._service_exec_stop = service_exec_stop @property def service_exec_stop_post(self): return self._service_exec_stop_post @service_exec_stop_post.setter def service_exec_stop_post(self, service_exec_stop_post): self._service_exec_stop_post = service_exec_stop_post @property def service_group(self): return self._service_group @service_group.setter def service_group(self, service_group): self._service_group = service_group @property def service_guess_main_pid(self): return self._service_guess_main_pid @service_guess_main_pid.setter def service_guess_main_pid(self, service_guess_main_pid): self._service_guess_main_pid = service_guess_main_pid @property def service_kill_mode(self): return self._service_kill_mode @service_kill_mode.setter def service_kill_mode(self, service_kill_mode): self._service_kill_mode = service_kill_mode @property def service_kill_signal(self): return self._service_kill_signal @service_kill_signal.setter def service_kill_signal(self, service_kill_signal): self._service_kill_signal = service_kill_signal @property def service_limit(self): return self._service_limit @service_limit.setter def service_limit(self, service_limit): self._service_limit = service_limit @property def service_memory_deny_write_execute(self): return self._service_memory_deny_write_execute @service_memory_deny_write_execute.setter def service_memory_deny_write_execute(self, service_memory_deny_write_execute): self._service_memory_deny_write_execute = service_memory_deny_write_execute @property def service_no_new_privileges(self): return self._service_no_new_privileges @service_no_new_privileges.setter def service_no_new_privileges(self, service_no_new_privileges): self._service_no_new_privileges = service_no_new_privileges @property def service_permissions_start_only(self): return self._service_permissions_start_only @service_permissions_start_only.setter def service_permissions_start_only(self, service_permissions_start_only): self._service_permissions_start_only = service_permissions_start_only @property def service_pid_file(self): return self._service_pid_file @service_pid_file.setter def service_pid_file(self, service_pid_file): self._service_pid_file = service_pid_file @property def service_private_devices(self): return self._service_private_devices @service_private_devices.setter def service_private_devices(self, service_private_devices): self._service_private_devices = service_private_devices @property def service_private_tmp(self): return self._service_private_tmp @service_private_tmp.setter def service_private_tmp(self, service_private_tmp): self._service_private_tmp = service_private_tmp @property def service_protect_home(self): return self._service_protect_home @service_protect_home.setter def service_protect_home(self, service_protect_home): self._service_protect_home = service_protect_home @property def service_protect_system(self): return self._service_protect_system @service_protect_system.setter def service_protect_system(self, service_protect_system): self._service_protect_system = service_protect_system @property def service_remain_after_exit(self): return self._service_remain_after_exit @service_remain_after_exit.setter def service_remain_after_exit(self, service_remain_after_exit): self._service_remain_after_exit = service_remain_after_exit @property def service_restart(self): return self._service_restart @service_restart.setter def service_restart(self, service_restart): self._service_restart = service_restart @property def service_restart_force_exit_status(self): return self._service_restart_force_exit_status @service_restart_force_exit_status.setter def service_restart_force_exit_status(self, service_restart_force_exit_status): self._service_restart_force_exit_status = service_restart_force_exit_status @property def service_restart_sec(self): return self._service_restart_sec @service_restart_sec.setter def service_restart_sec(self, service_restart_sec): self._service_restart_sec = service_restart_sec @property def service_runtime_directory(self): return self._service_runtime_directory @service_runtime_directory.setter def service_runtime_directory(self, service_runtime_directory): self._service_runtime_directory = service_runtime_directory @property def service_runtime_directory_mode(self): return self._service_runtime_directory_mode @service_runtime_directory_mode.setter def service_runtime_directory_mode(self, service_runtime_directory_mode): self._service_runtime_directory_mode = service_runtime_directory_mode @property def service_secure_bits(self): return self._service_secure_bits @service_secure_bits.setter def service_secure_bits(self, service_secure_bits): self._service_secure_bits = service_secure_bits @property def service_success_exit_status(self): return self._service_success_exit_status @service_success_exit_status.setter def service_success_exit_status(self, service_success_exit_status): self._service_success_exit_status = service_success_exit_status @property def service_system_call_architectures(self): return self._service_system_call_architectures @service_system_call_architectures.setter def service_system_call_architectures(self, service_system_call_architectures): self._service_system_call_architectures = service_system_call_architectures @property def service_tasks_max(self): return self._service_tasks_max @service_tasks_max.setter def service_tasks_max(self, service_tasks_max): self._service_tasks_max = service_tasks_max @property def service_timeout_sec(self): return self._service_timeout_sec @service_timeout_sec.setter def service_timeout_sec(self, service_timeout_sec): self._service_timeout_sec = service_timeout_sec @property def service_timeout_start_sec(self): return self._service_timeout_start_sec @service_timeout_start_sec.setter def service_timeout_start_sec(self, service_timeout_start_sec): self._service_timeout_start_sec = service_timeout_start_sec @property def service_timeout_stop_sec(self): return self._service_timeout_stop_sec @service_timeout_stop_sec.setter def service_timeout_stop_sec(self, service_timeout_stop_sec): self._service_timeout_stop_sec = service_timeout_stop_sec @property def service_type(self): return self._service_type @service_type.setter def service_type(self, service_type): self._service_type = service_type @property def service_user(self): return self._service_user @service_user.setter def service_user(self, service_user): self._service_user = service_user @property def service_working_directory(self): return self._service_working_directory @service_working_directory.setter def service_working_directory(self, service_working_directory): self._service_working_directory = service_working_directory @property def started(self): return self._started @started.setter def started(self, started): self._started = started @property def unit_after(self): return self._unit_after @unit_after.setter def unit_after(self, unit_after): self._unit_after = unit_after @property def unit_before(self): return self._unit_before @unit_before.setter def unit_before(self, unit_before): self._unit_before = unit_before @property def unit_binds_to(self): return self._unit_binds_to @unit_binds_to.setter def unit_binds_to(self, unit_binds_to): self._unit_binds_to = unit_binds_to @property def unit_condition(self): return self._unit_condition @unit_condition.setter def unit_condition(self, unit_condition): self._unit_condition = unit_condition @property def unit_conflicts(self): return self._unit_conflicts @unit_conflicts.setter def unit_conflicts(self, unit_conflicts): self._unit_conflicts = unit_conflicts @property def unit_description(self): return self._unit_description @unit_description.setter def unit_description(self, unit_description): self._unit_description = unit_description @property def unit_documentation(self): return self._unit_documentation @unit_documentation.setter def unit_documentation(self, unit_documentation): self._unit_documentation = unit_documentation @property def unit_part_of(self): return self._unit_part_of @unit_part_of.setter def unit_part_of(self, unit_part_of): self._unit_part_of = unit_part_of @property def unit_requires(self): return self._unit_requires @unit_requires.setter def unit_requires(self, unit_requires): self._unit_requires = unit_requires @property def unit_requisite(self): return self._unit_requisite @unit_requisite.setter def unit_requisite(self, unit_requisite): self._unit_requisite = unit_requisite @property def unit_start_limit_burst(self): return self._unit_start_limit_burst @unit_start_limit_burst.setter def unit_start_limit_burst(self, unit_start_limit_burst): self._unit_start_limit_burst = unit_start_limit_burst @property def unit_start_limit_interval_sec(self): return self._unit_start_limit_interval_sec @unit_start_limit_interval_sec.setter def unit_start_limit_interval_sec(self, unit_start_limit_interval_sec): self._unit_start_limit_interval_sec = unit_start_limit_interval_sec @property def unit_wants(self): return self._unit_wants @unit_wants.setter def unit_wants(self, unit_wants): self._unit_wants = unit_wants frecklet_class = SystemdServiceUnit