unit

package
v2.0.2 Latest Latest
Warning

This package is not in the latest version of its module.

 Go to latest Published: Jan 10, 2021 License: BSD-3-Clause Imports: 1 Imported by: 5

Documentation

Overview

Package unit provides mappings for the following categories: "Unit directives" (see https://www.freedesktop.org/software/systemd/man/systemd.directives.html).

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

This section is empty.

Types

type AutomountFile 

type AutomountFile struct {
	systemdconf.File

	Unit      UnitSection      // Generic information about the unit that is not dependent on the type of unit
	Automount AutomountSection // Information about the file system automount points it supervises
	Install   InstallSection   // Installation information for the unit
}

AutomountFile represents systemd.automount — Automount unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.automount.html for details)

type AutomountSection 

type AutomountSection struct {
	systemdconf.Section

	// Takes an absolute path of a directory of the automount point. If the automount point does not exist at time that the automount
	// point is installed, it is created. This string must be reflected in the unit filename. (See above.) This option is mandatory.
	Where systemdconf.Value

	// Directories of automount points (and any parent directories) are automatically created if needed. This option specifies
	// the file system access mode used when creating these directories. Takes an access mode in octal notation. Defaults to 0755.
	DirectoryMode systemdconf.Value

	// Configures an idle timeout. Once the mount has been idle for the specified time, systemd will attempt to unmount. Takes
	// a unit-less value in seconds, or a time span value such as "5min 20s". Pass 0 to disable the timeout logic. The timeout is disabled
	// by default.
	TimeoutIdleSec systemdconf.Value
}

AutomountSection represents information about the file system automount points it supervises (see https://www.freedesktop.org/software/systemd/man/systemd.automount.html#Options for details)

type DeviceFile 

type DeviceFile struct {
	systemdconf.File

	Unit    UnitSection    // Generic information about the unit that is not dependent on the type of unit
	Install InstallSection // Installation information for the unit
}

DeviceFile represents systemd.device — Device unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.device.html for details)

type ExecOptions 

type ExecOptions struct {
	// 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).
	WorkingDirectory systemdconf.Value

	// Takes a directory path relative to the host's root directory (i.e. the root of the system running the service manager).
	// Sets the root directory for executed processes, with the chroot system call. If this is used, it must be ensured that the
	// process binary and all its auxiliary files are available in the chroot() jail. Note that setting this parameter might result
	// in additional dependencies to be added to the unit (see above).
	//
	// The MountAPIVFS= and PrivateUsers= settings are particularly useful in conjunction with RootDirectory=. For details,
	// 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.
	RootDirectory systemdconf.Value

	// Takes a path to a block device node or regular file as argument. This call is similar to RootDirectory= however mounts a file
	// system hierarchy from a block device node or loopback file instead of a directory. The device node or file system image file
	// needs to contain a file system without a partition table, or a file system within an MBR/MS-DOS or GPT partition table with
	// only a single Linux-compatible partition, or a set of file systems within a GPT partition table that follows the Discoverable
	// Partitions Specification.
	//
	// When DevicePolicy= is set to "closed" or "strict", or set to "auto" and DeviceAllow= is set, then this setting adds /dev/loop-control
	// with rw mode, "block-loop" and "block-blkext" with rwm mode to DeviceAllow=. See systemd.resource-control for the details
	// about DevicePolicy= or DeviceAllow=. Also, see PrivateDevices= below, as it may change the setting of DevicePolicy=.
	//
	// Units making use of RootImage= automatically gain an After= dependency on systemd-udevd.service.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	RootImage systemdconf.Value

	// Takes a comma-separated list of mount options that will be used on disk images specified by RootImage=. Optionally a partition
	// name can be prefixed, followed by colon, in case the image has multiple partitions, otherwise partition name "root" is
	// implied. Options for multiple partitions can be specified in a single line with space separators. Assigning an empty string
	// removes previous assignments. Duplicated options are ignored. For a list of valid mount options, please refer to mount.
	//
	// Valid partition names follow the Discoverable Partitions Specification.
	//
	// 	+----------------+
	// 	| PARTITION NAME |
	// 	+----------------+
	// 	| root           |
	// 	| root-secondary |
	// 	| home           |
	// 	| srv            |
	// 	| esp            |
	// 	| xbootldr       |
	// 	| tmp            |
	// 	| var            |
	// 	| usr            |
	// 	+----------------+
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	RootImageOptions systemdconf.Value

	// Takes a data integrity (dm-verity) root hash specified in hexadecimal, or the path to a file containing a root hash in ASCII
	// hexadecimal format. This option enables data integrity checks using dm-verity, if the used image contains the appropriate
	// integrity data (see above) or if RootVerity= is used. The specified hash must match the root hash of integrity data, and
	// is usually at least 256 bits (and hence 64 formatted hexadecimal characters) long (in case of SHA256 for example). If this
	// option is not specified, but the image file carries the "user.verity.roothash" extended file attribute (see xattr),
	// then the root hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found
	// (or is not supported by the underlying file system), but a file with the .roothash suffix is found next to the image file,
	// bearing otherwise the same name (except if the image has the .raw suffix, in which case the root hash file must not have it
	// in its name), the root hash is read from it and automatically used, also as formatted hexadecimal characters.
	//
	// If the disk image contains a separate /usr/ partition it may also be Verity protected, in which case the root hash may configured
	// via an extended attribute "user.verity.usrhash" or a .usrhash file adjacent to the disk image. There's currently no option
	// to configure the root hash for the /usr/ file system via the unit file directly.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	RootHash systemdconf.Value

	// Takes a PKCS7 signature of the RootHash= option as a path to a DER-encoded signature file, or as an ASCII base64 string encoding
	// of a DER-encoded signature prefixed by "base64:". The dm-verity volume will only be opened if the signature of the root
	// hash is valid and signed by a public key present in the kernel keyring. If this option is not specified, but a file with the
	// .roothash.p7s suffix is found next to the image file, bearing otherwise the same name (except if the image has the .raw suffix,
	// in which case the signature file must not have it in its name), the signature is read from it and automatically used.
	//
	// If the disk image contains a separate /usr/ partition it may also be Verity protected, in which case the signature for the
	// root hash may configured via a .usrhash.p7s file adjacent to the disk image. There's currently no option to configure the
	// root hash signature for the /usr/ via the unit file directly.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	RootHashSignature systemdconf.Value

	// Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks using dm-verity, if RootImage=
	// is used and a root-hash is passed and if the used image itself does not contains the integrity data. The integrity data must
	// be matched by the root hash. If this option is not specified, but a file with the .verity suffix is found next to the image file,
	// bearing otherwise the same name (except if the image has the .raw suffix, in which case the verity data file must not have
	// it in its name), the verity data is read from it and automatically used.
	//
	// This option is supported only for disk images that contain a single file system, without an enveloping partition table.
	// Images that contain a GPT partition table should instead include both root file system and matching Verity data in the same
	// image, implementing the Discoverable Partition Specification.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	RootVerity systemdconf.Value

	// Takes a boolean argument. If on, a private mount namespace for the unit's processes is created and the API file systems /proc/,
	// /sys/, and /dev/ are mounted inside of it, unless they are already mounted. Note that this option has no effect unless used
	// in conjunction with RootDirectory=/RootImage= as these three mounts are generally mounted in the host anyway, and unless
	// the root directory is changed, the private mount namespace will be a 1:1 copy of the host's, and include these three mounts.
	// Note that the /dev/ file system of the host is bind mounted if this option is used without PrivateDevices=. To run the service
	// with a private, minimal version of /dev/, combine this option with PrivateDevices=.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	MountAPIVFS systemdconf.Value

	// Takes one of "noaccess", "invisible", "ptraceable" or "default" (which it defaults to). When set, this controls the "hidepid="
	// mount option of the "procfs" instance for the unit that controls which directories with process metainformation (/proc/PID)
	// are visible and accessible: when set to "noaccess" the ability to access most of other users' process metadata in /proc/
	// is taken away for processes of the service. When set to "invisible" processes owned by other users are hidden from /proc/.
	// If "ptraceable" all processes that cannot be ptrace()'ed by a process are hidden to it. If "default" no restrictions on
	// /proc/ access or visibility are made. For further details see The /proc Filesystem. It is generally recommended to run
	// most system services with this option set to "invisible". This option is implemented via file system namespacing, and
	// thus cannot be used with services that shall be able to install mount points in the host file system hierarchy. It also cannot
	// be used for services that need to access metainformation about other users' processes. This option implies MountAPIVFS=.
	//
	// If the kernel doesn't support per-mount point hidepid= mount options this setting remains without effect, and the unit's
	// processes will be able to access and see other process as if the option was not used.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	ProtectProc systemdconf.Value

	// Takes one of "all" (the default) and "pid". If the latter all files and directories not directly associated with process
	// management and introspection are made invisible in the /proc/ file system configured for the unit's processes. This controls
	// the "subset=" mount option of the "procfs" instance for the unit. For further details see The /proc Filesystem. Note that
	// Linux exposes various kernel APIs via /proc/, which are made unavailable with this setting. Since these APIs are used frequently
	// this option is useful only in a few, specific cases, and is not suitable for most non-trivial programs.
	//
	// Much like ProtectProc= above, this is implemented via file system mount namespacing, and hence the same restrictions
	// apply: it is only available to system services, it disables mount propagation to the host mount table, and it implies MountAPIVFS=.
	// Also, like ProtectProc= this setting is gracefully disabled if the used kernel does not support the "subset=" mount option
	// of "procfs".
	ProcSubset systemdconf.Value

	// Configures unit-specific bind mounts. A bind mount makes a particular file or directory available at an additional place
	// in the unit's view of the file system. Any bind mounts created with this option are specific to the unit, and are not visible
	// in the host's mount table. This option expects a whitespace separated list of bind mount definitions. Each definition
	// consists of a colon-separated triple of source path, destination path and option string, where the latter two are optional.
	// If only a source path is specified the source and destination is taken to be the same. The option string may be either "rbind"
	// or "norbind" for configuring a recursive or non-recursive bind mount. If the destination path is omitted, the option string
	// must be omitted too. Each bind mount definition may be prefixed with "-", in which case it will be ignored when its source
	// path does not exist.
	//
	// BindPaths= creates regular writable bind mounts (unless the source file system mount is already marked read-only), while
	// BindReadOnlyPaths= creates read-only bind mounts. These settings may be used more than once, each usage appends to the
	// unit's list of bind mounts. If the empty string is assigned to either of these two options the entire list of bind mounts defined
	// prior to this is reset. Note that in this case both read-only and regular bind mounts are reset, regardless which of the two
	// settings is used.
	//
	// This option is particularly useful when RootDirectory=/RootImage= is used. In this case the source path refers to a path
	// on the host file system, while the destination path refers to a path below the root directory of the unit.
	//
	// Note that the destination directory must exist or systemd must be able to create it. Thus, it is not possible to use those
	// options for mount points nested underneath paths specified in InaccessiblePaths=, or under /home/ and other protected
	// directories if ProtectHome=yes is specified. TemporaryFileSystem= with ":ro" or ProtectHome=tmpfs should be used
	// instead.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	BindPaths systemdconf.Value

	// Configures unit-specific bind mounts. A bind mount makes a particular file or directory available at an additional place
	// in the unit's view of the file system. Any bind mounts created with this option are specific to the unit, and are not visible
	// in the host's mount table. This option expects a whitespace separated list of bind mount definitions. Each definition
	// consists of a colon-separated triple of source path, destination path and option string, where the latter two are optional.
	// If only a source path is specified the source and destination is taken to be the same. The option string may be either "rbind"
	// or "norbind" for configuring a recursive or non-recursive bind mount. If the destination path is omitted, the option string
	// must be omitted too. Each bind mount definition may be prefixed with "-", in which case it will be ignored when its source
	// path does not exist.
	//
	// BindPaths= creates regular writable bind mounts (unless the source file system mount is already marked read-only), while
	// BindReadOnlyPaths= creates read-only bind mounts. These settings may be used more than once, each usage appends to the
	// unit's list of bind mounts. If the empty string is assigned to either of these two options the entire list of bind mounts defined
	// prior to this is reset. Note that in this case both read-only and regular bind mounts are reset, regardless which of the two
	// settings is used.
	//
	// This option is particularly useful when RootDirectory=/RootImage= is used. In this case the source path refers to a path
	// on the host file system, while the destination path refers to a path below the root directory of the unit.
	//
	// Note that the destination directory must exist or systemd must be able to create it. Thus, it is not possible to use those
	// options for mount points nested underneath paths specified in InaccessiblePaths=, or under /home/ and other protected
	// directories if ProtectHome=yes is specified. TemporaryFileSystem= with ":ro" or ProtectHome=tmpfs should be used
	// instead.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	BindReadOnlyPaths systemdconf.Value

	// This setting is similar to RootImage= in that it mounts a file system hierarchy from a block device node or loopback file,
	// but the destination directory can be specified as well as mount options. This option expects a whitespace separated list
	// of mount definitions. Each definition consists of a colon-separated tuple of source path and destination definitions,
	// optionally followed by another colon and a list of mount options.
	//
	// Mount options may be defined as a single comma-separated list of options, in which case they will be implicitly applied
	// to the root partition on the image, or a series of colon-separated tuples of partition name and mount options. Valid partition
	// names and mount options are the same as for RootImageOptions= setting described above.
	//
	// Each mount definition may be prefixed with "-", in which case it will be ignored when its source path does not exist. The source
	// argument is a path to a block device node or regular file. If source or destination contain a ":", it needs to be escaped as
	// "\:". The device node or file system image file needs to follow the same rules as specified for RootImage=. Any mounts created
	// with this option are specific to the unit, and are not visible in the host's mount table.
	//
	// These settings may be used more than once, each usage appends to the unit's list of mount paths. If the empty string is assigned,
	// the entire list of mount paths defined prior to this is reset.
	//
	// Note that the destination directory must exist or systemd must be able to create it. Thus, it is not possible to use those
	// options for mount points nested underneath paths specified in InaccessiblePaths=, or under /home/ and other protected
	// directories if ProtectHome=yes is specified.
	//
	// When DevicePolicy= is set to "closed" or "strict", or set to "auto" and DeviceAllow= is set, then this setting adds /dev/loop-control
	// with rw mode, "block-loop" and "block-blkext" with rwm mode to DeviceAllow=. See systemd.resource-control for the details
	// about DevicePolicy= or DeviceAllow=. Also, see PrivateDevices= below, as it may change the setting of DevicePolicy=.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	MountImages systemdconf.Value

	// 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 this enforces only weak restrictions on the user/group name syntax, but will generate warnings in many cases
	// where user/group names do not adhere to the following rules: the specified name should 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 and "_" (i.e. digits and "-" are not permitted
	// as first character). The user/group name must have at least one character, and at most 31. These restrictions are made in
	// order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux systems. For further
	// details on the names accepted and the names warned about see User/Group Name Syntax.
	//
	// 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 facility, which is applied at boot or package install time. If the
	// user does not exist by then program invocation will fail.
	//
	// If the User= setting is used the supplementary group list is initialized from the specified user's default group list,
	// as defined in the system's user and group database. Additional groups may be configured through the SupplementaryGroups=
	// setting (see below).
	User systemdconf.Value

	// 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 this enforces only weak restrictions on the user/group name syntax, but will generate warnings in many cases
	// where user/group names do not adhere to the following rules: the specified name should 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 and "_" (i.e. digits and "-" are not permitted
	// as first character). The user/group name must have at least one character, and at most 31. These restrictions are made in
	// order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux systems. For further
	// details on the names accepted and the names warned about see User/Group Name Syntax.
	//
	// 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 facility, which is applied at boot or package install time. If the
	// user does not exist by then program invocation will fail.
	//
	// If the User= setting is used the supplementary group list is initialized from the specified user's default group list,
	// as defined in the system's user and group database. Additional groups may be configured through the SupplementaryGroups=
	// setting (see below).
	Group systemdconf.Value

	// Takes a boolean parameter. If set, a UNIX user and group pair is allocated dynamically when the unit is started, and released
	// as soon as it is stopped. The user and group will not be added to /etc/passwd or /etc/group, but are managed transiently during
	// runtime. The nss-systemd glibc NSS module provides integration of these dynamic users/groups into the system's user
	// and group databases. The user and group name to use may be configured via User= and Group= (see above). If these options are
	// not used and dynamic user/group allocation is enabled for a unit, the name of the dynamic user/group is implicitly derived
	// from the unit name. If the unit name without the type suffix qualifies as valid user name it is used directly, otherwise a
	// name incorporating a hash of it is used. If a statically allocated user or group of the configured name already exists, it
	// is used and no dynamic user/group is allocated. Note that if User= is specified and the static group with the name exists,
	// then it is required that the static user with the name already exists. Similarly, if Group= is specified and the static user
	// with the name exists, then it is required that the static group with the name already exists. Dynamic users/groups are allocated
	// from the UID/GID range 61184…65519. It is recommended to avoid this range for regular system or login users. At any point
	// in time each UID/GID from this range is only assigned to zero or one dynamically allocated users/groups in use. However,
	// UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as part of a unit for which
	// dynamic users/groups are enabled do not leave files or directories owned by these users/groups around, as a different
	// unit might get the same UID/GID assigned later on, and thus gain access to these files or directories. If DynamicUser= is
	// enabled, RemoveIPC= and PrivateTmp= are implied (and cannot be turned off). This ensures that the lifetime of IPC objects
	// and temporary files created by the executed processes is bound to the runtime of the service, and hence the lifetime of the
	// dynamic user/group. Since /tmp/ and /var/tmp/ are usually the only world-writable directories on a system this ensures
	// that a unit making use of dynamic user/group allocation cannot leave files around after unit termination. Furthermore
	// NoNewPrivileges= and RestrictSUIDSGID= are implicitly enabled (and cannot be disabled), to ensure that processes invoked
	// cannot take benefit or create SUID/SGID files or directories. Moreover ProtectSystem=strict and ProtectHome=read-only
	// are implied, thus prohibiting the service to write to arbitrary file system locations. In order to allow the service to
	// write to certain directories, they have to be allow-listed using ReadWritePaths=, but care must be taken so that UID/GID
	// recycling doesn't create security issues involving files created by the service. Use RuntimeDirectory= (see below)
	// in order to assign a writable runtime directory to a service, owned by the dynamic user/group and removed automatically
	// when the unit is terminated. Use StateDirectory=, CacheDirectory= and LogsDirectory= in order to assign a set of writable
	// directories for specific purposes to the service in a way that they are protected from vulnerabilities due to UID reuse
	// (see below). If this option is enabled, care should be taken that the unit's processes do not get access to directories outside
	// of these explicitly configured and managed ones. Specifically, do not use BindPaths= and be careful with AF_UNIX file
	// descriptor passing for directory file descriptors, as this would permit processes to create files or directories owned
	// by the dynamic user/group that are not subject to the lifecycle and access guarantees of the service. Defaults to off.
	DynamicUser systemdconf.Value

	// Sets the supplementary Unix groups the processes are executed as. This takes a space-separated list of group names or IDs.
	// This option may be specified more than once, in which case all listed groups are set as supplementary groups. When the empty
	// string is assigned, the list of supplementary groups is reset, and all assignments prior to this one will have no effect.
	// In any way, this option does not override, but extends the list of supplementary groups configured in the system group database
	// for the user. This does not affect commands prefixed with "+".
	SupplementaryGroups systemdconf.Value

	// Sets the PAM service name to set up a session as. If set, the executed process will be registered as a PAM session under the
	// specified service name. This is only useful in conjunction with the User= setting, and is otherwise ignored. If not set,
	// no PAM session will be opened for the executed processes. See pam for details.
	//
	// Note that for each unit making use of this option a PAM session handler process will be maintained as part of the unit and stays
	// around as long as the unit is active, to ensure that appropriate actions can be taken when the unit and hence the PAM session
	// terminates. This process is named "(sd-pam)" and is an immediate child process of the unit's main process.
	//
	// Note that when this option is used for a unit it is very likely (depending on PAM configuration) that the main unit process
	// will be migrated to its own session scope unit when it is activated. This process will hence be associated with two units:
	// the unit it was originally started from (and for which PAMName= was configured), and the session scope unit. Any child processes
	// of that process will however be associated with the session scope unit only. This has implications when used in combination
	// with NotifyAccess=all, as these child processes will not be able to affect changes in the original unit through notification
	// messages. These messages will be considered belonging to the session scope unit and not the original unit. It is hence not
	// recommended to use PAMName= in combination with NotifyAccess=all.
	PAMName systemdconf.Value

	// Controls which capabilities to include in the capability bounding set for the executed process. See capabilities 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 "+".
	//
	// Use systemd-analyze's capability command to retrieve a list of capabilities defined on the local system.
	//
	// 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.
	CapabilityBoundingSet systemdconf.Value

	// 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 "+".
	AmbientCapabilities systemdconf.Value

	// 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=, ProtectKernelLogs=,
	// ProtectClock=, 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.
	NoNewPrivileges systemdconf.Value

	// 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 for details.
	SecureBits systemdconf.Value

	// Set the SELinux security context of the executed process. If set, this will override the automated domain transition.
	// However, the policy still needs to authorize the transition. This directive is ignored if SELinux is disabled. If prefixed
	// by "-", all errors will be ignored. This does not affect commands prefixed with "+". See setexeccon for details.
	SELinuxContext systemdconf.Value

	// Takes a profile name as argument. The process executed by the unit will switch to this profile when started. Profiles must
	// already be loaded in the kernel, or the unit will fail. If prefixed by "-", all errors will be ignored. This setting has no
	// effect if AppArmor is not enabled. This setting does not affect commands prefixed with "+".
	AppArmorProfile systemdconf.Value

	// Takes a SMACK64 security label as argument. The process executed by the unit will be started under this label and SMACK will
	// decide whether the process is allowed to run or not, based on it. The process will continue to run under the label specified
	// here unless the executable has its own SMACK64EXEC label, in which case the process will transition to run under that label.
	// When not specified, the label that systemd is running under is used. This directive is ignored if SMACK is disabled.
	//
	// The value may be prefixed by "-", in which case all errors will be ignored. An empty value may be specified to unset previous
	// assignments. This does not affect commands prefixed with "+".
	SmackProcessLabel systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitCPU systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitFSIZE systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitDATA systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitSTACK systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitCORE systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitRSS systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitNOFILE systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitAS systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitNPROC systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitMEMLOCK systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitLOCKS systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitSIGPENDING systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitMSGQUEUE systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitNICE systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitRTPRIO systemdconf.Value

	// Set soft and hard limits on various resources for executed processes. See setrlimit 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 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 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, MemoryMax= is a more powerful (and
	// working) replacement for LimitRSS=.
	//
	// Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=,
	// DefaultLimitFSIZE=, … options available in systemd-system.conf, and – if not configured there – the kernel or per-user
	// defaults, as defined by the OS (the latter only for user services, see below).
	//
	// For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e.
	// a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for
	// the user manager itself when it was first invoked, as the user's service manager generally lacks the privileges to do so.
	// In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit
	// to the maximum of the hard limit as configured for the user. To raise the user's limits further, the available configuration
	// mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure
	// higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user's service manager,
	// i.e. the user's instance of user@.service. After making such changes, make sure to restart the user's service manager.
	//
	// 	+------------------+-------------------+----------------------------+
	// 	|    DIRECTIVE     | ULIMIT EQUIVALENT |            UNIT            |
	// 	+------------------+-------------------+----------------------------+
	// 	| LimitCPU=        | ulimit -t         | Seconds                    |
	// 	| LimitFSIZE=      | ulimit -f         | Bytes                      |
	// 	| LimitDATA=       | ulimit -d         | Bytes                      |
	// 	| LimitSTACK=      | ulimit -s         | Bytes                      |
	// 	| LimitCORE=       | ulimit -c         | Bytes                      |
	// 	| LimitRSS=        | ulimit -m         | Bytes                      |
	// 	| LimitNOFILE=     | ulimit -n         | Number of File Descriptors |
	// 	| LimitAS=         | ulimit -v         | Bytes                      |
	// 	| LimitNPROC=      | ulimit -u         | Number of Processes        |
	// 	| LimitMEMLOCK=    | ulimit -l         | Bytes                      |
	// 	| LimitLOCKS=      | ulimit -x         | Number of Locks            |
	// 	| LimitSIGPENDING= | ulimit -i         | Number of Queued Signals   |
	// 	| LimitMSGQUEUE=   | ulimit -q         | Bytes                      |
	// 	| LimitNICE=       | ulimit -e         | Nice Level                 |
	// 	| LimitRTPRIO=     | ulimit -r         | Realtime Priority          |
	// 	| LimitRTTIME=     | No equivalent     | Microseconds               |
	// 	+------------------+-------------------+----------------------------+
	LimitRTTIME systemdconf.Value

	// Controls the file mode creation mask. Takes an access mode in octal notation. See umask for details. Defaults to 0022 for
	// system units. For user units the default value is inherited from the per-user service manager (whose default is in turn
	// inherited from the system service manager, and thus typically also is 0022 — unless overridden by a PAM module). In order
	// to change the per-user mask for all user services, consider setting the UMask= setting of the user's user@.service system
	// service instance. The per-user umask may also be set via the umask field of a user's JSON User Record (for users managed by
	// systemd-homed.service this field may be controlled via homectl --umask=). It may also be set via a PAM module, such as pam_umask.
	UMask systemdconf.Value

	// Controls which types of memory mappings will be saved if the process dumps core (using the /proc/pid/coredump_filter
	// file). Takes a whitespace-separated combination of mapping type names or numbers (with the default base 16). Mapping
	// type names are private-anonymous, shared-anonymous, private-file-backed, shared-file-backed, elf-headers, private-huge,
	// shared-huge, private-dax, shared-dax, and the special values all (all types) and default (the kernel default of "private-anonymous
	// shared-anonymous elf-headers private-huge"). See core for the meaning of the mapping types. When specified multiple
	// times, all specified masks are ORed. When not set, or if the empty value is assigned, the inherited value is not changed.
	//
	// 	CoredumpFilter=default private-dax shared-dax
	CoredumpFilter systemdconf.Value

	// Controls how the kernel session keyring is set up for the service (see session-keyring for details on the session keyring).
	// Takes one of inherit, private, shared. If set to inherit no special keyring setup is done, and the kernel's default behaviour
	// is applied. If private is used a new session keyring is allocated when a service process is invoked, and it is not linked up
	// with any user keyring. This is the recommended setting for system services, as this ensures that multiple services running
	// under the same system user ID (in particular the root user) do not share their key material among each other. If shared is
	// used a new session keyring is allocated as for private, but the user keyring of the user configured with User= is linked into
	// it, so that keys assigned to the user may be requested by the unit's processes. In this modes multiple units running processes
	// under the same user ID may share key material. Unless inherit is selected the unique invocation ID for the unit (see below)
	// is added as a protected key by the name "invocation_id" to the newly created session keyring. Defaults to private for services
	// of the system service manager and to inherit for non-service units and for services of the user service manager.
	KeyringMode systemdconf.Value

	// Sets the adjustment value for the Linux kernel's Out-Of-Memory (OOM) killer score for executed processes. Takes an integer
	// between -1000 (to disable OOM killing of processes of this unit) and 1000 (to make killing of processes of this unit under
	// memory pressure very likely). See proc.txt for details. If not specified defaults to the OOM score adjustment level of
	// the service manager itself, which is normally at 0.
	//
	// Use the OOMPolicy= setting of service units to configure how the service manager shall react to the kernel OOM killer terminating
	// a process of the service. See systemd.service for details.
	OOMScoreAdjust systemdconf.Value

	// Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the accuracy of wake-ups triggered
	// by timers. See prctl for more information. Note that in contrast to most other time span definitions this parameter takes
	// an integer value in nano-seconds if no unit is specified. The usual time units are understood too.
	TimerSlackNSec systemdconf.Value

	// Controls which kernel architecture uname shall report, when invoked by unit processes. Takes one of the architecture
	// identifiers x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, s390 or s390x. Which personality architectures are supported
	// depends on the system architecture. Usually the 64bit versions of the various system architectures support their immediate
	// 32bit personality architecture counterpart, but no others. For example, x86-64 systems support the x86-64 and x86 personalities
	// but no others. The personality feature is useful when running 32-bit services on a 64-bit host system. If not specified,
	// the personality is left unmodified and thus reflects the personality of the host system's kernel.
	Personality systemdconf.Value

	// Takes a boolean argument. If true, causes SIGPIPE to be ignored in the executed process. Defaults to true because SIGPIPE
	// generally is useful only in shell pipelines.
	IgnoreSIGPIPE systemdconf.Value

	// Sets the default nice level (scheduling priority) for executed processes. Takes an integer between -20 (highest priority)
	// and 19 (lowest priority). See setpriority for details.
	Nice systemdconf.Value

	// Sets the CPU scheduling policy for executed processes. Takes one of other, batch, idle, fifo or rr. See sched_setscheduler
	// for details.
	CPUSchedulingPolicy systemdconf.Value

	// Sets the CPU scheduling priority for executed processes. The available priority range depends on the selected CPU scheduling
	// policy (see above). For real-time scheduling policies an integer between 1 (lowest priority) and 99 (highest priority)
	// can be used. See sched_setscheduler for details.
	CPUSchedulingPriority systemdconf.Value

	// Takes a boolean argument. If true, elevated CPU scheduling priorities and policies will be reset when the executed processes
	// call fork, and can hence not leak into child processes. See sched_setscheduler for details. Defaults to false.
	CPUSchedulingResetOnFork systemdconf.Value

	// Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges separated by either whitespace
	// or commas. Alternatively, takes a special "numa" value in which case systemd automatically derives allowed CPU range
	// based on the value of NUMAMask= option. CPU ranges are specified by the lower and upper CPU indices separated by a dash. This
	// option may be specified more than once, in which case the specified CPU affinity masks are merged. If the empty string is
	// assigned, the mask is reset, all assignments prior to this will have no effect. See sched_setaffinity for details.
	CPUAffinity systemdconf.Value

	// Controls the NUMA memory policy of the executed processes. Takes a policy type, one of: default, preferred, bind, interleave
	// and local. A list of NUMA nodes that should be associated with the policy must be specified in NUMAMask=. For more details
	// on each policy please see, set_mempolicy. For overall overview of NUMA support in Linux see, numa.
	NUMAPolicy systemdconf.Value

	// Controls the NUMA node list which will be applied alongside with selected NUMA policy. Takes a list of NUMA nodes and has
	// the same syntax as a list of CPUs for CPUAffinity= option or special "all" value which will include all available NUMA nodes
	// in the mask. Note that the list of NUMA nodes is not required for default and local policies and for preferred policy we expect
	// a single NUMA node.
	NUMAMask systemdconf.Value

	// Sets the I/O scheduling class for executed processes. Takes an integer between 0 and 3 or one of the strings none, realtime,
	// best-effort or idle. If the empty string is assigned to this option, all prior assignments to both IOSchedulingClass=
	// and IOSchedulingPriority= have no effect. See ioprio_set for details.
	IOSchedulingClass systemdconf.Value

	// Sets the I/O scheduling priority for executed processes. Takes an integer between 0 (highest priority) and 7 (lowest priority).
	// The available priorities depend on the selected I/O scheduling class (see above). If the empty string is assigned to this
	// option, all prior assignments to both IOSchedulingClass= and IOSchedulingPriority= have no effect. See ioprio_set
	// for details.
	IOSchedulingPriority systemdconf.Value

	// Takes a boolean argument or the special values "full" or "strict". If true, mounts the /usr/ and the boot loader directories
	// (/boot and /efi) 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.
	ProtectSystem systemdconf.Value

	// 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 still allowing
	// necessary directories to be made visible when listed in 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= with ":ro".
	//
	// 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.
	ProtectHome systemdconf.Value

	// These options take a whitespace-separated list of directory names. The specified directory names must be relative, and
	// may not include "..". If set, when the unit is started, one or more directories by the specified names will be created (including
	// their parents) below the locations defined in the following table. Also, the corresponding environment variable will
	// be defined with the full paths of the directories. If multiple directories are set, then in the environment variable the
	// paths are concatenated with colon (":").
	//
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	|        DIRECTORY        | BELOW PATH FOR SYSTEM UNITS | BELOW PATH FOR USER UNITS | ENVIRONMENT VARIABLE SET |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	| RuntimeDirectory=       | /run/                       | $XDG_RUNTIME_DIR          | $RUNTIME_DIRECTORY       |
	// 	| StateDirectory=         | /var/lib/                   | $XDG_CONFIG_HOME          | $STATE_DIRECTORY         |
	// 	| CacheDirectory=         | /var/cache/                 | $XDG_CACHE_HOME           | $CACHE_DIRECTORY         |
	// 	| LogsDirectory=          | /var/log/                   | $XDG_CONFIG_HOME/log/     | $LOGS_DIRECTORY          |
	// 	| ConfigurationDirectory= | /etc/                       | $XDG_CONFIG_HOME          | $CONFIGURATION_DIRECTORY |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	//
	// In case of RuntimeDirectory= the innermost subdirectories are removed when the unit is stopped. It is possible to preserve
	// the specified directories in this case if RuntimeDirectoryPreserve= is configured to restart or yes (see below). The
	// directories specified with StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= are not
	// removed when the unit is stopped.
	//
	// Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified
	// in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured
	// ones, all files and directories below the specified directories as well as the directories themselves will have their
	// file ownership recursively changed to match what is configured. As an optimization, if the specified directories are
	// already owned by the right user and group, files and directories below of them are left as-is, even if they do not match what
	// is requested. The innermost specified directories will have their access mode adjusted to the what is specified in RuntimeDirectoryMode=,
	// StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= and ConfigurationDirectoryMode=.
	//
	// These options imply BindPaths= for the specified paths. When combined with RootDirectory= or RootImage= these paths
	// always reside on the host and are mounted from there into the unit's file system namespace.
	//
	// If DynamicUser= is used in conjunction with StateDirectory=, the logic for CacheDirectory= and LogsDirectory= is slightly
	// altered: the directories are created below /var/lib/private, /var/cache/private and /var/log/private, respectively,
	// which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot
	// be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
	// perspective of the host and from inside the unit, the relevant directories hence always appear directly below /var/lib,
	// /var/cache and /var/log.
	//
	// Use RuntimeDirectory= to manage one or more runtime directories for the unit and bind their lifetime to the daemon runtime.
	// This is particularly useful for unprivileged daemons that cannot create runtime directories in /run/ due to lack of privileges,
	// and to make sure the runtime directory is cleaned up automatically after use. For runtime directories that require more
	// complex or different configuration or lifetime guarantees, please consider using tmpfiles.d.
	//
	// The directories defined by these options are always created under the standard paths used by systemd (/var/, /run/, /etc/,
	// …). If the service needs directories in a different location, a different mechanism has to be used to create them.
	//
	// tmpfiles.d provides functionality that overlaps with these options. Using these options is recommended, because the
	// lifetime of the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the tmpfiles.d
	// configuration is executed before the unit is started.
	//
	// To remove any of the directories created by these settings, use the systemctl clean … command on the relevant units, see
	// systemctl for details.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar baz
	//
	// the service manager creates /run/foo (if it does not exist), /run/foo/bar, and /run/baz. The directories /run/foo/bar
	// and /run/baz except /run/foo are owned by the user and group specified in User= and Group=, and removed when the service
	// is stopped.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar StateDirectory=aaa/bbb ccc
	//
	// then the environment variable "RUNTIME_DIRECTORY" is set with "/run/foo/bar", and "STATE_DIRECTORY" is set with "/var/lib/aaa/bbb:/var/lib/ccc".
	RuntimeDirectory systemdconf.Value

	// These options take a whitespace-separated list of directory names. The specified directory names must be relative, and
	// may not include "..". If set, when the unit is started, one or more directories by the specified names will be created (including
	// their parents) below the locations defined in the following table. Also, the corresponding environment variable will
	// be defined with the full paths of the directories. If multiple directories are set, then in the environment variable the
	// paths are concatenated with colon (":").
	//
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	|        DIRECTORY        | BELOW PATH FOR SYSTEM UNITS | BELOW PATH FOR USER UNITS | ENVIRONMENT VARIABLE SET |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	| RuntimeDirectory=       | /run/                       | $XDG_RUNTIME_DIR          | $RUNTIME_DIRECTORY       |
	// 	| StateDirectory=         | /var/lib/                   | $XDG_CONFIG_HOME          | $STATE_DIRECTORY         |
	// 	| CacheDirectory=         | /var/cache/                 | $XDG_CACHE_HOME           | $CACHE_DIRECTORY         |
	// 	| LogsDirectory=          | /var/log/                   | $XDG_CONFIG_HOME/log/     | $LOGS_DIRECTORY          |
	// 	| ConfigurationDirectory= | /etc/                       | $XDG_CONFIG_HOME          | $CONFIGURATION_DIRECTORY |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	//
	// In case of RuntimeDirectory= the innermost subdirectories are removed when the unit is stopped. It is possible to preserve
	// the specified directories in this case if RuntimeDirectoryPreserve= is configured to restart or yes (see below). The
	// directories specified with StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= are not
	// removed when the unit is stopped.
	//
	// Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified
	// in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured
	// ones, all files and directories below the specified directories as well as the directories themselves will have their
	// file ownership recursively changed to match what is configured. As an optimization, if the specified directories are
	// already owned by the right user and group, files and directories below of them are left as-is, even if they do not match what
	// is requested. The innermost specified directories will have their access mode adjusted to the what is specified in RuntimeDirectoryMode=,
	// StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= and ConfigurationDirectoryMode=.
	//
	// These options imply BindPaths= for the specified paths. When combined with RootDirectory= or RootImage= these paths
	// always reside on the host and are mounted from there into the unit's file system namespace.
	//
	// If DynamicUser= is used in conjunction with StateDirectory=, the logic for CacheDirectory= and LogsDirectory= is slightly
	// altered: the directories are created below /var/lib/private, /var/cache/private and /var/log/private, respectively,
	// which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot
	// be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
	// perspective of the host and from inside the unit, the relevant directories hence always appear directly below /var/lib,
	// /var/cache and /var/log.
	//
	// Use RuntimeDirectory= to manage one or more runtime directories for the unit and bind their lifetime to the daemon runtime.
	// This is particularly useful for unprivileged daemons that cannot create runtime directories in /run/ due to lack of privileges,
	// and to make sure the runtime directory is cleaned up automatically after use. For runtime directories that require more
	// complex or different configuration or lifetime guarantees, please consider using tmpfiles.d.
	//
	// The directories defined by these options are always created under the standard paths used by systemd (/var/, /run/, /etc/,
	// …). If the service needs directories in a different location, a different mechanism has to be used to create them.
	//
	// tmpfiles.d provides functionality that overlaps with these options. Using these options is recommended, because the
	// lifetime of the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the tmpfiles.d
	// configuration is executed before the unit is started.
	//
	// To remove any of the directories created by these settings, use the systemctl clean … command on the relevant units, see
	// systemctl for details.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar baz
	//
	// the service manager creates /run/foo (if it does not exist), /run/foo/bar, and /run/baz. The directories /run/foo/bar
	// and /run/baz except /run/foo are owned by the user and group specified in User= and Group=, and removed when the service
	// is stopped.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar StateDirectory=aaa/bbb ccc
	//
	// then the environment variable "RUNTIME_DIRECTORY" is set with "/run/foo/bar", and "STATE_DIRECTORY" is set with "/var/lib/aaa/bbb:/var/lib/ccc".
	StateDirectory systemdconf.Value

	// These options take a whitespace-separated list of directory names. The specified directory names must be relative, and
	// may not include "..". If set, when the unit is started, one or more directories by the specified names will be created (including
	// their parents) below the locations defined in the following table. Also, the corresponding environment variable will
	// be defined with the full paths of the directories. If multiple directories are set, then in the environment variable the
	// paths are concatenated with colon (":").
	//
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	|        DIRECTORY        | BELOW PATH FOR SYSTEM UNITS | BELOW PATH FOR USER UNITS | ENVIRONMENT VARIABLE SET |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	| RuntimeDirectory=       | /run/                       | $XDG_RUNTIME_DIR          | $RUNTIME_DIRECTORY       |
	// 	| StateDirectory=         | /var/lib/                   | $XDG_CONFIG_HOME          | $STATE_DIRECTORY         |
	// 	| CacheDirectory=         | /var/cache/                 | $XDG_CACHE_HOME           | $CACHE_DIRECTORY         |
	// 	| LogsDirectory=          | /var/log/                   | $XDG_CONFIG_HOME/log/     | $LOGS_DIRECTORY          |
	// 	| ConfigurationDirectory= | /etc/                       | $XDG_CONFIG_HOME          | $CONFIGURATION_DIRECTORY |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	//
	// In case of RuntimeDirectory= the innermost subdirectories are removed when the unit is stopped. It is possible to preserve
	// the specified directories in this case if RuntimeDirectoryPreserve= is configured to restart or yes (see below). The
	// directories specified with StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= are not
	// removed when the unit is stopped.
	//
	// Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified
	// in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured
	// ones, all files and directories below the specified directories as well as the directories themselves will have their
	// file ownership recursively changed to match what is configured. As an optimization, if the specified directories are
	// already owned by the right user and group, files and directories below of them are left as-is, even if they do not match what
	// is requested. The innermost specified directories will have their access mode adjusted to the what is specified in RuntimeDirectoryMode=,
	// StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= and ConfigurationDirectoryMode=.
	//
	// These options imply BindPaths= for the specified paths. When combined with RootDirectory= or RootImage= these paths
	// always reside on the host and are mounted from there into the unit's file system namespace.
	//
	// If DynamicUser= is used in conjunction with StateDirectory=, the logic for CacheDirectory= and LogsDirectory= is slightly
	// altered: the directories are created below /var/lib/private, /var/cache/private and /var/log/private, respectively,
	// which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot
	// be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
	// perspective of the host and from inside the unit, the relevant directories hence always appear directly below /var/lib,
	// /var/cache and /var/log.
	//
	// Use RuntimeDirectory= to manage one or more runtime directories for the unit and bind their lifetime to the daemon runtime.
	// This is particularly useful for unprivileged daemons that cannot create runtime directories in /run/ due to lack of privileges,
	// and to make sure the runtime directory is cleaned up automatically after use. For runtime directories that require more
	// complex or different configuration or lifetime guarantees, please consider using tmpfiles.d.
	//
	// The directories defined by these options are always created under the standard paths used by systemd (/var/, /run/, /etc/,
	// …). If the service needs directories in a different location, a different mechanism has to be used to create them.
	//
	// tmpfiles.d provides functionality that overlaps with these options. Using these options is recommended, because the
	// lifetime of the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the tmpfiles.d
	// configuration is executed before the unit is started.
	//
	// To remove any of the directories created by these settings, use the systemctl clean … command on the relevant units, see
	// systemctl for details.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar baz
	//
	// the service manager creates /run/foo (if it does not exist), /run/foo/bar, and /run/baz. The directories /run/foo/bar
	// and /run/baz except /run/foo are owned by the user and group specified in User= and Group=, and removed when the service
	// is stopped.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar StateDirectory=aaa/bbb ccc
	//
	// then the environment variable "RUNTIME_DIRECTORY" is set with "/run/foo/bar", and "STATE_DIRECTORY" is set with "/var/lib/aaa/bbb:/var/lib/ccc".
	CacheDirectory systemdconf.Value

	// These options take a whitespace-separated list of directory names. The specified directory names must be relative, and
	// may not include "..". If set, when the unit is started, one or more directories by the specified names will be created (including
	// their parents) below the locations defined in the following table. Also, the corresponding environment variable will
	// be defined with the full paths of the directories. If multiple directories are set, then in the environment variable the
	// paths are concatenated with colon (":").
	//
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	|        DIRECTORY        | BELOW PATH FOR SYSTEM UNITS | BELOW PATH FOR USER UNITS | ENVIRONMENT VARIABLE SET |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	| RuntimeDirectory=       | /run/                       | $XDG_RUNTIME_DIR          | $RUNTIME_DIRECTORY       |
	// 	| StateDirectory=         | /var/lib/                   | $XDG_CONFIG_HOME          | $STATE_DIRECTORY         |
	// 	| CacheDirectory=         | /var/cache/                 | $XDG_CACHE_HOME           | $CACHE_DIRECTORY         |
	// 	| LogsDirectory=          | /var/log/                   | $XDG_CONFIG_HOME/log/     | $LOGS_DIRECTORY          |
	// 	| ConfigurationDirectory= | /etc/                       | $XDG_CONFIG_HOME          | $CONFIGURATION_DIRECTORY |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	//
	// In case of RuntimeDirectory= the innermost subdirectories are removed when the unit is stopped. It is possible to preserve
	// the specified directories in this case if RuntimeDirectoryPreserve= is configured to restart or yes (see below). The
	// directories specified with StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= are not
	// removed when the unit is stopped.
	//
	// Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified
	// in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured
	// ones, all files and directories below the specified directories as well as the directories themselves will have their
	// file ownership recursively changed to match what is configured. As an optimization, if the specified directories are
	// already owned by the right user and group, files and directories below of them are left as-is, even if they do not match what
	// is requested. The innermost specified directories will have their access mode adjusted to the what is specified in RuntimeDirectoryMode=,
	// StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= and ConfigurationDirectoryMode=.
	//
	// These options imply BindPaths= for the specified paths. When combined with RootDirectory= or RootImage= these paths
	// always reside on the host and are mounted from there into the unit's file system namespace.
	//
	// If DynamicUser= is used in conjunction with StateDirectory=, the logic for CacheDirectory= and LogsDirectory= is slightly
	// altered: the directories are created below /var/lib/private, /var/cache/private and /var/log/private, respectively,
	// which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot
	// be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
	// perspective of the host and from inside the unit, the relevant directories hence always appear directly below /var/lib,
	// /var/cache and /var/log.
	//
	// Use RuntimeDirectory= to manage one or more runtime directories for the unit and bind their lifetime to the daemon runtime.
	// This is particularly useful for unprivileged daemons that cannot create runtime directories in /run/ due to lack of privileges,
	// and to make sure the runtime directory is cleaned up automatically after use. For runtime directories that require more
	// complex or different configuration or lifetime guarantees, please consider using tmpfiles.d.
	//
	// The directories defined by these options are always created under the standard paths used by systemd (/var/, /run/, /etc/,
	// …). If the service needs directories in a different location, a different mechanism has to be used to create them.
	//
	// tmpfiles.d provides functionality that overlaps with these options. Using these options is recommended, because the
	// lifetime of the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the tmpfiles.d
	// configuration is executed before the unit is started.
	//
	// To remove any of the directories created by these settings, use the systemctl clean … command on the relevant units, see
	// systemctl for details.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar baz
	//
	// the service manager creates /run/foo (if it does not exist), /run/foo/bar, and /run/baz. The directories /run/foo/bar
	// and /run/baz except /run/foo are owned by the user and group specified in User= and Group=, and removed when the service
	// is stopped.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar StateDirectory=aaa/bbb ccc
	//
	// then the environment variable "RUNTIME_DIRECTORY" is set with "/run/foo/bar", and "STATE_DIRECTORY" is set with "/var/lib/aaa/bbb:/var/lib/ccc".
	LogsDirectory systemdconf.Value

	// These options take a whitespace-separated list of directory names. The specified directory names must be relative, and
	// may not include "..". If set, when the unit is started, one or more directories by the specified names will be created (including
	// their parents) below the locations defined in the following table. Also, the corresponding environment variable will
	// be defined with the full paths of the directories. If multiple directories are set, then in the environment variable the
	// paths are concatenated with colon (":").
	//
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	|        DIRECTORY        | BELOW PATH FOR SYSTEM UNITS | BELOW PATH FOR USER UNITS | ENVIRONMENT VARIABLE SET |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	// 	| RuntimeDirectory=       | /run/                       | $XDG_RUNTIME_DIR          | $RUNTIME_DIRECTORY       |
	// 	| StateDirectory=         | /var/lib/                   | $XDG_CONFIG_HOME          | $STATE_DIRECTORY         |
	// 	| CacheDirectory=         | /var/cache/                 | $XDG_CACHE_HOME           | $CACHE_DIRECTORY         |
	// 	| LogsDirectory=          | /var/log/                   | $XDG_CONFIG_HOME/log/     | $LOGS_DIRECTORY          |
	// 	| ConfigurationDirectory= | /etc/                       | $XDG_CONFIG_HOME          | $CONFIGURATION_DIRECTORY |
	// 	+-------------------------+-----------------------------+---------------------------+--------------------------+
	//
	// In case of RuntimeDirectory= the innermost subdirectories are removed when the unit is stopped. It is possible to preserve
	// the specified directories in this case if RuntimeDirectoryPreserve= is configured to restart or yes (see below). The
	// directories specified with StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= are not
	// removed when the unit is stopped.
	//
	// Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified
	// in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured
	// ones, all files and directories below the specified directories as well as the directories themselves will have their
	// file ownership recursively changed to match what is configured. As an optimization, if the specified directories are
	// already owned by the right user and group, files and directories below of them are left as-is, even if they do not match what
	// is requested. The innermost specified directories will have their access mode adjusted to the what is specified in RuntimeDirectoryMode=,
	// StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= and ConfigurationDirectoryMode=.
	//
	// These options imply BindPaths= for the specified paths. When combined with RootDirectory= or RootImage= these paths
	// always reside on the host and are mounted from there into the unit's file system namespace.
	//
	// If DynamicUser= is used in conjunction with StateDirectory=, the logic for CacheDirectory= and LogsDirectory= is slightly
	// altered: the directories are created below /var/lib/private, /var/cache/private and /var/log/private, respectively,
	// which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot
	// be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
	// perspective of the host and from inside the unit, the relevant directories hence always appear directly below /var/lib,
	// /var/cache and /var/log.
	//
	// Use RuntimeDirectory= to manage one or more runtime directories for the unit and bind their lifetime to the daemon runtime.
	// This is particularly useful for unprivileged daemons that cannot create runtime directories in /run/ due to lack of privileges,
	// and to make sure the runtime directory is cleaned up automatically after use. For runtime directories that require more
	// complex or different configuration or lifetime guarantees, please consider using tmpfiles.d.
	//
	// The directories defined by these options are always created under the standard paths used by systemd (/var/, /run/, /etc/,
	// …). If the service needs directories in a different location, a different mechanism has to be used to create them.
	//
	// tmpfiles.d provides functionality that overlaps with these options. Using these options is recommended, because the
	// lifetime of the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the tmpfiles.d
	// configuration is executed before the unit is started.
	//
	// To remove any of the directories created by these settings, use the systemctl clean … command on the relevant units, see
	// systemctl for details.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar baz
	//
	// the service manager creates /run/foo (if it does not exist), /run/foo/bar, and /run/baz. The directories /run/foo/bar
	// and /run/baz except /run/foo are owned by the user and group specified in User= and Group=, and removed when the service
	// is stopped.
	//
	// Example: if a system service unit has the following,
	//
	// 	RuntimeDirectory=foo/bar StateDirectory=aaa/bbb ccc
	//
	// then the environment variable "RUNTIME_DIRECTORY" is set with "/run/foo/bar", and "STATE_DIRECTORY" is set with "/var/lib/aaa/bbb:/var/lib/ccc".
	ConfigurationDirectory systemdconf.Value

	// Specifies the access mode of the directories specified in RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=,
	// or ConfigurationDirectory=, respectively, as an octal number. Defaults to 0755. See "Permissions" in path_resolution
	// for a discussion of the meaning of permission bits.
	RuntimeDirectoryMode systemdconf.Value

	// Specifies the access mode of the directories specified in RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=,
	// or ConfigurationDirectory=, respectively, as an octal number. Defaults to 0755. See "Permissions" in path_resolution
	// for a discussion of the meaning of permission bits.
	StateDirectoryMode systemdconf.Value

	// Specifies the access mode of the directories specified in RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=,
	// or ConfigurationDirectory=, respectively, as an octal number. Defaults to 0755. See "Permissions" in path_resolution
	// for a discussion of the meaning of permission bits.
	CacheDirectoryMode systemdconf.Value

	// Specifies the access mode of the directories specified in RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=,
	// or ConfigurationDirectory=, respectively, as an octal number. Defaults to 0755. See "Permissions" in path_resolution
	// for a discussion of the meaning of permission bits.
	LogsDirectoryMode systemdconf.Value

	// Specifies the access mode of the directories specified in RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=,
	// or ConfigurationDirectory=, respectively, as an octal number. Defaults to 0755. See "Permissions" in path_resolution
	// for a discussion of the meaning of permission bits.
	ConfigurationDirectoryMode systemdconf.Value

	// Takes a boolean argument or restart. If set to no (the default), the directories specified in RuntimeDirectory= are always
	// removed when the service stops. If set to restart the directories are preserved when the service is both automatically
	// and manually restarted. Here, the automatic restart means the operation specified in Restart=, and manual restart means
	// the one triggered by systemctl restart foo.service. If set to yes, then the directories are not removed when the service
	// is stopped. Note that since the runtime directory /run/ is a mount point of "tmpfs", then for system services the directories
	// specified in RuntimeDirectory= are removed when the system is rebooted.
	RuntimeDirectoryPreserve systemdconf.Value

	// Configures a timeout on the clean-up operation requested through systemctl clean …, see systemctl for details. Takes
	// the usual time values and defaults to infinity, i.e. by default no timeout is applied. If a timeout is configured the clean
	// operation will be aborted forcibly when the timeout is reached, potentially leaving resources on disk.
	TimeoutCleanSec systemdconf.Value

	// Sets up a new file system namespace for executed processes. These options may be used to limit access a process has to the
	// file system. Each setting takes a space-separated list of paths relative to the host's root directory (i.e. the system
	// running the service manager). Note that if paths contain symlinks, they are resolved relative to the root directory set
	// with RootDirectory=/RootImage=.
	//
	// Paths listed in ReadWritePaths= are accessible from within the namespace with the same access modes as from outside of
	// it. Paths listed in ReadOnlyPaths= are accessible for reading only, writing will be refused even if the usual file access
	// controls would permit this. Nest ReadWritePaths= inside of ReadOnlyPaths= in order to provide writable subdirectories
	// within read-only directories. Use ReadWritePaths= in order to allow-list specific paths for write access if ProtectSystem=strict
	// is used.
	//
	// Paths listed in InaccessiblePaths= will be made inaccessible for processes inside the namespace along with everything
	// below them in the file system hierarchy. This may be more restrictive than desired, because it is not possible to nest ReadWritePaths=,
	// ReadOnlyPaths=, BindPaths=, or BindReadOnlyPaths= inside it. For a more flexible option, see TemporaryFileSystem=.
	//
	// Non-directory paths may be specified as well. These options may be specified more than once, in which case all paths listed
	// will have limited access from within the namespace. If the empty string is assigned to this option, the specific list is
	// reset, and all prior assignments have no effect.
	//
	// Paths in ReadWritePaths=, ReadOnlyPaths= and InaccessiblePaths= may be prefixed with "-", in which case they will be
	// ignored when they do not exist. If prefixed with "+" the paths are taken relative to the root directory of the unit, as configured
	// with RootDirectory=/RootImage=, instead of relative to the root directory of the host (see above). When combining "-"
	// and "+" on the same path make sure to specify "-" first, and "+" second.
	//
	// Note that these settings will disconnect propagation of mounts from the unit's processes to the host. This means that this
	// setting may not be used for services which shall be able to install mount points in the main mount namespace. For ReadWritePaths=
	// and ReadOnlyPaths= propagation in the other direction is not affected, i.e. mounts created on the host generally appear
	// in the unit processes' namespace, and mounts removed on the host also disappear there too. In particular, note that mount
	// propagation from host to unit will result in unmodified mounts to be created in the unit's namespace, i.e. writable mounts
	// appearing on the host will be writable in the unit's namespace too, even when propagated below a path marked with ReadOnlyPaths=!
	// Restricting access with these options hence does not extend to submounts of a directory that are created later on. This
	// means the lock-down offered by that setting is not complete, and does not offer full protection.
	//
	// Note that the effect of these settings may be undone by privileged processes. In order to set up an effective sandboxed environment
	// for a unit it is thus recommended to combine these settings with either CapabilityBoundingSet=~CAP_SYS_ADMIN or SystemCallFilter=~@mount.
	//
	// These options are only available for system services and are not supported for services running in per-user instances
	// of the service manager.
	ReadWritePaths systemdconf.Value

	// Sets up a new file system namespace for executed processes. These options may be used to limit access a process has to the
	// file system. Each setting takes a space-separated list of paths relative to the host's root directory (i.e. the system
	// running the service manager). Note that if paths contain symlinks, they are resolved relative to the root directory set
	// with RootDirectory=/RootImage=.
	//
	// Paths listed in ReadWritePaths= are accessible from within the namespace with the same access modes as from outside of
	// it. Paths listed in ReadOnlyPaths= are accessible for reading only, writing will be refused even if the usual file access
	// controls would permit this. Nest ReadWritePaths= inside of ReadOnlyPaths= in order to provide writable subdirectories
	// within read-only directories. Use ReadWritePaths= in order to allow-list specific paths for write access if ProtectSystem=strict
	// is used.
	//
	// Paths listed in InaccessiblePaths= will be made inaccessible for processes inside the namespace along with everything
	// below them in the file system hierarchy. This may be more restrictive than desired, because it is not possible to nest ReadWritePaths=,
	// ReadOnlyPaths=, BindPaths=, or BindReadOnlyPaths= inside it. For a more flexible option, see TemporaryFileSystem=.
	//
	// Non-directory paths may be specified as well. These options may be specified more than once, in which case all paths listed
	// will have limited access from within the namespace. If the empty string is assigned to this option, the specific list is
	// reset, and all prior assignments have no effect.
	//
	// Paths in ReadWritePaths=, ReadOnlyPaths= and InaccessiblePaths= may be prefixed with "-", in which case they will be
	// ignored when they do not exist. If prefixed with "+" the paths are taken relative to the root directory of the unit, as configured
	// with RootDirectory=/RootImage=, instead of relative to the root directory of the host (see above). When combining "-"
	// and "+" on the same path make sure to specify "-" first, and "+" second.
	//
	// Note that these settings will disconnect propagation of mounts from the unit's processes to the host. This means that this
	// setting may not be used for services which shall be able to install mount points in the main mount namespace. For ReadWritePaths=
	// and ReadOnlyPaths= propagation in the other direction is not affected, i.e. mounts created on the host generally appear
	// in the unit processes' namespace, and mounts removed on the host also disappear there too. In particular, note that mount
	// propagation from host to unit will result in unmodified mounts to be created in the unit's namespace, i.e. writable mounts
	// appearing on the host will be writable in the unit's namespace too, even when propagated below a path marked with ReadOnlyPaths=!
	// Restricting access with these options hence does not extend to submounts of a directory that are created later on. This
	// means the lock-down offered by that setting is not complete, and does not offer full protection.
	//
	// Note that the effect of these settings may be undone by privileged processes. In order to set up an effective sandboxed environment
	// for a unit it is thus recommended to combine these settings with either CapabilityBoundingSet=~CAP_SYS_ADMIN or SystemCallFilter=~@mount.
	//
	// These options are only available for system services and are not supported for services running in per-user instances
	// of the service manager.
	ReadOnlyPaths systemdconf.Value

	// Sets up a new file system namespace for executed processes. These options may be used to limit access a process has to the
	// file system. Each setting takes a space-separated list of paths relative to the host's root directory (i.e. the system
	// running the service manager). Note that if paths contain symlinks, they are resolved relative to the root directory set
	// with RootDirectory=/RootImage=.
	//
	// Paths listed in ReadWritePaths= are accessible from within the namespace with the same access modes as from outside of
	// it. Paths listed in ReadOnlyPaths= are accessible for reading only, writing will be refused even if the usual file access
	// controls would permit this. Nest ReadWritePaths= inside of ReadOnlyPaths= in order to provide writable subdirectories
	// within read-only directories. Use ReadWritePaths= in order to allow-list specific paths for write access if ProtectSystem=strict
	// is used.
	//
	// Paths listed in InaccessiblePaths= will be made inaccessible for processes inside the namespace along with everything
	// below them in the file system hierarchy. This may be more restrictive than desired, because it is not possible to nest ReadWritePaths=,
	// ReadOnlyPaths=, BindPaths=, or BindReadOnlyPaths= inside it. For a more flexible option, see TemporaryFileSystem=.
	//
	// Non-directory paths may be specified as well. These options may be specified more than once, in which case all paths listed
	// will have limited access from within the namespace. If the empty string is assigned to this option, the specific list is
	// reset, and all prior assignments have no effect.
	//
	// Paths in ReadWritePaths=, ReadOnlyPaths= and InaccessiblePaths= may be prefixed with "-", in which case they will be
	// ignored when they do not exist. If prefixed with "+" the paths are taken relative to the root directory of the unit, as configured
	// with RootDirectory=/RootImage=, instead of relative to the root directory of the host (see above). When combining "-"
	// and "+" on the same path make sure to specify "-" first, and "+" second.
	//
	// Note that these settings will disconnect propagation of mounts from the unit's processes to the host. This means that this
	// setting may not be used for services which shall be able to install mount points in the main mount namespace. For ReadWritePaths=
	// and ReadOnlyPaths= propagation in the other direction is not affected, i.e. mounts created on the host generally appear
	// in the unit processes' namespace, and mounts removed on the host also disappear there too. In particular, note that mount
	// propagation from host to unit will result in unmodified mounts to be created in the unit's namespace, i.e. writable mounts
	// appearing on the host will be writable in the unit's namespace too, even when propagated below a path marked with ReadOnlyPaths=!
	// Restricting access with these options hence does not extend to submounts of a directory that are created later on. This
	// means the lock-down offered by that setting is not complete, and does not offer full protection.
	//
	// Note that the effect of these settings may be undone by privileged processes. In order to set up an effective sandboxed environment
	// for a unit it is thus recommended to combine these settings with either CapabilityBoundingSet=~CAP_SYS_ADMIN or SystemCallFilter=~@mount.
	//
	// These options are only available for system services and are not supported for services running in per-user instances
	// of the service manager.
	InaccessiblePaths systemdconf.Value

	// Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file system namespace is
	// set up for executed processes, and a temporary file system is mounted on each mount point. This option may be specified more
	// than once, in which case temporary file systems are mounted on all listed mount points. If the empty string is assigned to
	// this option, the list is reset, and all prior assignments have no effect. Each mount point may optionally be suffixed with
	// a colon (":") and mount options such as "size=10%" or "ro". By default, each temporary file system is mounted with "nodev,strictatime,mode=0755".
	// These can be disabled by explicitly specifying the corresponding mount options, e.g., "dev" or "nostrictatime".
	//
	// This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary files or directories
	// can be still accessed by combining with BindPaths= or BindReadOnlyPaths=:
	//
	// Example: if a unit has the following,
	//
	// 	TemporaryFileSystem=/var:ro BindReadOnlyPaths=/var/lib/systemd
	//
	// then the invoked processes by the unit cannot see any files or directories under /var/ except for /var/lib/systemd or its
	// contents.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	TemporaryFileSystem systemdconf.Value

	// 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 are 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 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 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.
	PrivateTmp systemdconf.Value

	// 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 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 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.
	PrivateDevices systemdconf.Value

	// Takes a boolean argument. If true, sets up a new network namespace for the executed processes and configures only the loopback
	// network device "lo" inside it. No other network devices will be available to the executed process. This is useful to turn
	// off network access by the executed process. Defaults to false. It is possible to run two or more units within the same private
	// network namespace by using the JoinsNamespaceOf= directive, see systemd.unit for details. Note that this option will
	// disconnect all socket families from the host, including AF_NETLINK and AF_UNIX. Effectively, for AF_NETLINK this means
	// that device configuration events received from systemd-udevd.service are not delivered to the unit's processes. And
	// for AF_UNIX this has the effect that AF_UNIX sockets in the abstract socket namespace of the host will become unavailable
	// to the unit's processes (however, those located in the file system will continue to be accessible).
	//
	// Note that the implementation of this setting might be impossible (for example if network namespaces are not available),
	// and the unit should be written in a way that does not solely rely on this setting for security.
	//
	// When this option is used on a socket unit any sockets bound on behalf of this unit will be bound within a private network namespace.
	// This may be combined with JoinsNamespaceOf= to listen on sockets inside of network namespaces of other services.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	PrivateNetwork systemdconf.Value

	// Takes an absolute file system path refererring to a Linux network namespace pseudo-file (i.e. a file like /proc/$PID/ns/net
	// or a bind mount or symlink to one). When set the invoked processes are added to the network namespace referenced by that path.
	// The path has to point to a valid namespace file at the moment the processes are forked off. If this option is used PrivateNetwork=
	// has no effect. If this option is used together with JoinsNamespaceOf= then it only has an effect if this unit is started before
	// any of the listed units that have PrivateNetwork= or NetworkNamespacePath= configured, as otherwise the network namespace
	// of those units is reused.
	//
	// When this option is used on a socket unit any sockets bound on behalf of this unit will be bound within the specified network
	// namespace.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	NetworkNamespacePath systemdconf.Value

	// Takes a boolean argument. If true, sets up a new user namespace for the executed processes and configures a minimal user
	// and group mapping, that maps the "root" user and group as well as the unit's own user and group to themselves and everything
	// else to the "nobody" user and group. This is useful to securely detach the user and group databases used by the unit from the
	// rest of the system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects
	// and other resources owned by users/groups not equaling "root" or the unit's own will stay visible from within the unit but
	// appear owned by the "nobody" user and group. If this mode is enabled, all unit processes are run without privileges in the
	// host user namespace (regardless if the unit's own user/group is "root" or not). Specifically this means that the process
	// will have zero process capabilities on the host's user namespace, but full capabilities within the service's user namespace.
	// Settings such as CapabilityBoundingSet= will affect only the latter, and there's no way to acquire additional capabilities
	// in the host's user namespace. Defaults to off.
	//
	// When this setting is set up by a per-user instance of the service manager, the mapping of the "root" user and group to itself
	// is omitted (unless the user manager is root). Additionally, in the per-user instance manager case, the user namespace
	// will be set up before most other namespaces. This means that combining PrivateUsers=true with other namespaces will enable
	// use of features not normally supported by the per-user instances of the service manager.
	//
	// This setting is particularly useful in conjunction with RootDirectory=/RootImage=, as the need to synchronize the user
	// and group databases in the root directory and on the host is reduced, as the only users and groups who need to be matched are
	// "root", "nobody" and the unit's own user and group.
	//
	// Note that the implementation of this setting might be impossible (for example if user namespaces are not available), and
	// the unit should be written in a way that does not solely rely on this setting for security.
	PrivateUsers systemdconf.Value

	// Takes a boolean argument. When set, sets up a new UTS namespace for the executed processes. In addition, changing hostname
	// or domainname is prevented. Defaults to off.
	//
	// Note that the implementation of this setting might be impossible (for example if UTS namespaces are not available), and
	// the unit should be written in a way that does not solely rely on this setting for security.
	//
	// Note that when this option is enabled for a service hostname changes no longer propagate from the system into the service,
	// it is hence not suitable for services that need to take notice of system hostname changes dynamically.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	ProtectHostname systemdconf.Value

	// Takes a boolean argument. If set, writes to the hardware clock or system clock will be denied. It is recommended to turn this
	// on for most services that do not need modify the clock. Defaults to off. Enabling this option removes CAP_SYS_TIME and CAP_WAKE_ALARM
	// from the capability bounding set for this unit, installs a system call filter to block calls that can set the clock, and DeviceAllow=char-rtc
	// r is implied. This ensures /dev/rtc0, /dev/rtc1, etc. are made read-only to the service. See systemd.resource-control
	// for the details about DeviceAllow=.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	ProtectClock systemdconf.Value

	// Takes a boolean argument. If true, kernel variables accessible through /proc/sys/, /sys/, /proc/sysrq-trigger, /proc/latency_stats,
	// /proc/acpi, /proc/timer_stats, /proc/fs and /proc/irq will be made read-only to all processes of the unit. Usually,
	// tunable kernel variables should be initialized only at boot-time, for example with the sysctl.d mechanism. Few services
	// need to write to these at runtime; it is hence recommended to turn this on for most services. For this setting the same restrictions
	// regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Defaults to off.
	// If turned on and if running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. services for
	// which User= is set), NoNewPrivileges=yes is implied. Note that this option does not prevent indirect changes to kernel
	// tunables effected by IPC calls to other processes. However, InaccessiblePaths= may be used to make relevant IPC file system
	// objects inaccessible. If ProtectKernelTunables= is set, MountAPIVFS=yes is implied.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	ProtectKernelTunables systemdconf.Value

	// Takes a boolean argument. If true, explicit module loading will be denied. This allows module load and unload operations
	// to be turned off on modular kernels. It is recommended to turn this on for most services that do not need special file systems
	// or extra kernel modules to work. Defaults to off. Enabling this option removes CAP_SYS_MODULE from the capability bounding
	// set for the unit, and installs a system call filter to block module system calls, also /usr/lib/modules is made inaccessible.
	// For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related
	// calls, see above. Note that limited automatic module loading due to user configuration or kernel mapping tables might
	// still happen as side effect of requested user operations, both privileged and unprivileged. To disable module auto-load
	// feature please see sysctl.d kernel.modules_disabled mechanism and /proc/sys/kernel/modules_disabled documentation.
	// 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.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	ProtectKernelModules systemdconf.Value

	// Takes a boolean argument. If true, access to the kernel log ring buffer will be denied. It is recommended to turn this on for
	// most services that do not need to read from or write to the kernel log ring buffer. Enabling this option removes CAP_SYSLOG
	// from the capability bounding set for this unit, and installs a system call filter to block the syslog system call (not to
	// be confused with the libc API syslog for userspace logging). The kernel exposes its log buffer to userspace via /dev/kmsg
	// and /proc/kmsg. If enabled, these are made inaccessible to all the processes in the unit.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	ProtectKernelLogs systemdconf.Value

	// Takes a boolean argument. If true, the Linux Control Groups (cgroups) hierarchies accessible through /sys/fs/cgroup/
	// will be made read-only to all processes of the unit. Except for container managers no services should require write access
	// to the control groups hierarchies; it is hence recommended to turn this on for most services. For this setting the same restrictions
	// regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Defaults to off.
	// If ProtectControlGroups= is set, MountAPIVFS=yes is implied.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	ProtectControlGroups systemdconf.Value

	// Restricts the set of socket address families accessible to the processes of this unit. Takes a space-separated list of
	// address family names to allow-list, such as AF_UNIX, AF_INET or AF_INET6. When prefixed with ~ the listed address families
	// will be applied as deny list, otherwise as allow list. Note that this restricts access to the socket system call only. Sockets
	// passed into the process by other means (for example, by using socket activation with socket units, see systemd.socket)
	// are unaffected. Also, sockets created with socketpair() (which creates connected AF_UNIX sockets only) are unaffected.
	// Note that this option has no effect on 32-bit x86, s390, s390x, mips, mips-le, ppc, ppc-le, ppc64, ppc64-le and is ignored
	// (but works correctly on other ABIs, including x86-64). 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=nobody), NoNewPrivileges=yes
	// is implied. By default, no restrictions apply, all address families are accessible to processes. If assigned the empty
	// string, any previous address family restriction changes are undone. This setting does not affect commands prefixed with
	// "+".
	//
	// Use this option to limit exposure of processes to remote access, in particular via exotic and sensitive network protocols,
	// such as AF_PACKET. Note that in most cases, the local AF_UNIX address family should be included in the configured allow
	// list as it is frequently used for local communication, including for syslog logging.
	RestrictAddressFamilies systemdconf.Value

	// Restricts access to Linux namespace functionality for the processes of this unit. For details about Linux namespaces,
	// see namespaces. Either takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the
	// default), no restrictions on namespace creation and switching are made. If true, access to any kind of namespacing is prohibited.
	// Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of any combination of:
	// cgroup, ipc, net, mnt, pid, user and uts. Any namespace type listed is made accessible to the unit's processes, access to
	// namespace types not listed is prohibited (allow-listing). By prepending the list with a single tilde character ("~")
	// the effect may be inverted: only the listed namespace types will be made inaccessible, all unlisted ones are permitted
	// (deny-listing). If the empty string is assigned, the default namespace restrictions are applied, which is equivalent
	// to false. This option may appear more than once, in which case the namespace types are merged by OR, or by AND if the lines are
	// prefixed with "~" (see examples below). Internally, this setting limits access to the unshare, clone and setns system
	// calls, taking the specified flags parameters into account. Note that — if this option is used — in addition to restricting
	// creation and switching of the specified types of namespaces (or all of them, if true) access to the setns() system call with
	// a zero flags parameter is prohibited. This setting is only supported on x86, x86-64, mips, mips-le, mips64, mips64-le,
	// mips64-n32, mips64-le-n32, ppc64, ppc64-le, s390 and s390x, and enforces no restrictions on other architectures. If
	// running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=), NoNewPrivileges=yes
	// is implied.
	//
	// Example: if a unit has the following,
	//
	// 	RestrictNamespaces=cgroup ipc RestrictNamespaces=cgroup net
	//
	// then cgroup, ipc, and net are set. If the second line is prefixed with "~", e.g.,
	//
	// 	RestrictNamespaces=cgroup ipc RestrictNamespaces=~cgroup net
	//
	// then, only ipc is set.
	RestrictNamespaces systemdconf.Value

	// Takes a boolean argument. If set, locks down the personality system call so that the kernel execution domain may not be changed
	// from the default or the personality selected with Personality= directive. This may be useful to improve security, because
	// odd personality emulations may be poorly tested and source of vulnerabilities. If running in user mode, or in system mode,
	// but without the CAP_SYS_ADMIN capability (e.g. setting User=), NoNewPrivileges=yes is implied.
	LockPersonality systemdconf.Value

	// 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 system calls with both PROT_EXEC and PROT_WRITE set, mprotect
	// or pkey_mprotect system calls with PROT_EXEC set and shmat 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.
	MemoryDenyWriteExecute systemdconf.Value

	// Takes a boolean argument. If set, any attempts to enable realtime scheduling in a process of the unit are refused. This restricts
	// access to realtime task scheduling policies such as SCHED_FIFO, SCHED_RR or SCHED_DEADLINE. See sched for details about
	// these scheduling policies. If running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g.
	// setting User=), NoNewPrivileges=yes is implied. Realtime scheduling policies may be used to monopolize CPU time for
	// longer periods of time, and may hence be used to lock up or otherwise trigger Denial-of-Service situations on the system.
	// It is hence recommended to restrict access to realtime scheduling to the few programs that actually require them. Defaults
	// to off.
	RestrictRealtime systemdconf.Value

	// Takes a boolean argument. If set, any attempts to set the set-user-ID (SUID) or set-group-ID (SGID) bits on files or directories
	// will be denied (for details on these bits see inode). If running in user mode, or in system mode, but without the CAP_SYS_ADMIN
	// capability (e.g. setting User=), NoNewPrivileges=yes is implied. As the SUID/SGID bits are mechanisms to elevate privileges,
	// and allows users to acquire the identity of other users, it is recommended to restrict creation of SUID/SGID files to the
	// few programs that actually require them. Note that this restricts marking of any type of file system object with these bits,
	// including both regular files and directories (where the SGID is a different meaning than for files, see documentation).
	// This option is implied if DynamicUser= is enabled. Defaults to off.
	RestrictSUIDSGID systemdconf.Value

	// Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and group the processes of this unit
	// are run as are removed when the unit is stopped. This setting only has an effect if at least one of User=, Group= and DynamicUser=
	// are used. It has no effect on IPC objects owned by the root user. Specifically, this removes System V semaphores, as well
	// as System V and POSIX shared memory segments and message queues. If multiple units use the same user or group the IPC objects
	// are removed when the last of these units is stopped. This setting is implied if DynamicUser= is set.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	RemoveIPC systemdconf.Value

	// Takes a boolean parameter. If set, the processes of this unit will be run in their own private file system (mount) namespace
	// with all mount propagation from the processes towards the host's main file system namespace turned off. This means any
	// file system mount points established or removed by the unit's processes will be private to them and not be visible to the
	// host. However, file system mount points established or removed on the host will be propagated to the unit's processes.
	// See mount_namespaces for details on file system namespaces. Defaults to off.
	//
	// When turned on, this executes three operations for each invoked process: a new CLONE_NEWNS namespace is created, after
	// which all existing mounts are remounted to MS_SLAVE to disable propagation from the unit's processes to the host (but leaving
	// propagation in the opposite direction in effect). Finally, the mounts are remounted again to the propagation mode configured
	// with MountFlags=, see below.
	//
	// File system namespaces are set up individually for each process forked off by the service manager. Mounts established
	// in the namespace of the process created by ExecStartPre= will hence be cleaned up automatically as soon as that process
	// exits and will not be available to subsequent processes forked off for ExecStart= (and similar applies to the various other
	// commands configured for units). Similarly, JoinsNamespaceOf= does not permit sharing kernel mount namespaces between
	// units, it only enables sharing of the /tmp/ and /var/tmp/ directories.
	//
	// Other file system namespace unit settings — PrivateMounts=, PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=,
	// ReadOnlyPaths=, InaccessiblePaths=, ReadWritePaths=, … — also enable file system namespacing in a fashion equivalent
	// to this option. Hence it is primarily useful to explicitly request this behaviour if none of the other settings are used.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	PrivateMounts systemdconf.Value

	// Takes a mount propagation setting: shared, slave or private, which controls whether file system mount points in the file
	// system namespaces set up for this unit's processes will receive or propagate mounts and unmounts from other file system
	// namespaces. See mount for details on mount propagation, and the three propagation flags in particular.
	//
	// This setting only controls the final propagation setting in effect on all mount points of the file system namespace created
	// for each process of this unit. Other file system namespacing unit settings (see the discussion in PrivateMounts= above)
	// will implicitly disable mount and unmount propagation from the unit's processes towards the host by changing the propagation
	// setting of all mount points in the unit's file system namespace to slave first. Setting this option to shared does not reestablish
	// propagation in that case.
	//
	// If not set – but file system namespaces are enabled through another file system namespace unit setting – shared mount propagation
	// is used, but — as mentioned — as slave is applied first, propagation from the unit's processes to the host is still turned
	// off.
	//
	// It is not recommended to use private mount propagation for units, as this means temporary mounts (such as removable media)
	// of the host will stay mounted and thus indefinitely busy in forked off processes, as unmount propagation events won't be
	// received by the file system namespace of the unit.
	//
	// Usually, it is best to leave this setting unmodified, and use higher level file system namespacing options instead, in
	// particular PrivateMounts=, see above.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	MountFlags systemdconf.Value

	// Takes a space-separated list of system call names. If this setting is used, all system calls executed by the unit processes
	// except for the listed ones will result in immediate process termination with the SIGSYS signal (allow-listing). (See
	// SystemCallErrorNumber= below for changing the default action). If the first character of the list is "~", the effect is
	// inverted: only the listed system calls will result in immediate process termination (deny-listing). Deny-listed system
	// calls and system call groups may optionally be suffixed with a colon (":") and "errno" error number (between 0 and 4095)
	// or errno name such as EPERM, EACCES or EUCLEAN (see errno for a full list). This value will be returned when a deny-listed
	// system call is triggered, instead of terminating the processes immediately. Special setting "kill" can be used to explicitly
	// specify killing. This value takes precedence over the one given in SystemCallErrorNumber=, see below. If running in user
	// mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=nobody), NoNewPrivileges=yes
	// is implied. This feature makes use of the Secure Computing Mode 2 interfaces of the kernel ('seccomp filtering') and is
	// useful for enforcing a minimal sandboxing environment. Note that the execve(), exit(), exit_group(), getrlimit(),
	// rt_sigreturn(), sigreturn() system calls and the system calls for querying time and sleeping are implicitly allow-listed
	// and do not need to be listed explicitly. This option may be specified more than once, in which case the filter masks are merged.
	// If the empty string is assigned, the filter is reset, all prior assignments will have no effect. This does not affect commands
	// prefixed with "+".
	//
	// 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.
	//
	// Note that strict system call filters may impact execution and error handling code paths of the service invocation. Specifically,
	// access to the execve() system call is required for the execution of the service binary — if it is blocked service invocation
	// will necessarily fail. Also, if execution of the service binary fails for some reason (for example: missing service executable),
	// the error handling logic might require access to an additional set of system calls in order to process and log this failure
	// correctly. It might be necessary to temporarily disable system call filters in order to simplify debugging of such failures.
	//
	// If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered will take precedence
	// and will dictate the default action (termination or approval of a system call). Then the next occurrences of this option
	// will add or delete the listed system calls from the set of the filtered system calls, depending of its type and the default
	// action. (For example, if you have started with an allow list rule for read() and write(), and right after it add a deny list
	// rule for write(), then write() will be removed from the set.)
	//
	// As the number of possible system calls is large, predefined sets of system calls are provided. A set starts with "@" character,
	// followed by name of the set.
	//
	// 	+-----------------+----------------------------------------------------------------------------------+
	// 	|       SET       |                                   DESCRIPTION                                    |
	// 	+-----------------+----------------------------------------------------------------------------------+
	// 	| @aio            | Asynchronous I/O (io_setup, io_submit, and related calls)                        |
	// 	| @basic-io       | System calls for basic I/O: reading, writing, seeking, file descriptor           |
	// 	|                 | duplication and closing (read, write, and related calls)                         |
	// 	| @chown          | Changing file ownership (chown, fchownat, and related calls)                     |
	// 	| @clock          | System calls for changing the system clock (adjtimex, settimeofday, and related  |
	// 	|                 | calls)                                                                           |
	// 	| @cpu-emulation  | System calls for CPU emulation functionality (vm86 and related calls)            |
	// 	| @debug          | Debugging, performance monitoring and tracing functionality (ptrace,             |
	// 	|                 | perf_event_open and related calls)                                               |
	// 	| @file-system    | File system operations: opening, creating files and directories for read and     |
	// 	|                 | write, renaming and removing them, reading file properties, or creating hard and |
	// 	|                 | symbolic links                                                                   |
	// 	| @io-event       | Event loop system calls (poll, select, epoll, eventfd and related calls)         |
	// 	| @ipc            | Pipes, SysV IPC, POSIX Message Queues and other IPC (mq_overview, svipc)         |
	// 	| @keyring        | Kernel keyring access (keyctl and related calls)                                 |
	// 	| @memlock        | Locking of memory in RAM (mlock, mlockall and related calls)                     |
	// 	| @module         | Loading and unloading of kernel modules (init_module, delete_module and related  |
	// 	|                 | calls)                                                                           |
	// 	| @mount          | Mounting and unmounting of file systems (mount, chroot, and related calls)       |
	// 	| @network-io     | Socket I/O (including local AF_UNIX): socket, unix                               |
	// 	| @obsolete       | Unusual, obsolete or unimplemented (create_module, gtty, …)                      |
	// 	| @privileged     | All system calls which need super-user capabilities (capabilities)               |
	// 	| @process        | Process control, execution, namespacing operations (clone, kill, namespaces, …)  |
	// 	| @raw-io         | Raw I/O port access (ioperm, iopl, pciconfig_read(), …)                          |
	// 	| @reboot         | System calls for rebooting and reboot preparation (reboot, kexec(), …)           |
	// 	| @resources      | System calls for changing resource limits, memory and scheduling parameters      |
	// 	|                 | (setrlimit, setpriority, …)                                                      |
	// 	| @setuid         | System calls for changing user ID and group ID credentials, (setuid, setgid,     |
	// 	|                 | setresuid, …)                                                                    |
	// 	| @signal         | System calls for manipulating and handling process signals (signal, sigprocmask, |
	// 	|                 | …)                                                                               |
	// 	| @swap           | System calls for enabling/disabling swap devices (swapon, swapoff)               |
	// 	| @sync           | Synchronizing files and memory to disk (fsync, msync, and related calls)         |
	// 	| @system-service | A reasonable set of system calls used by common system services, excluding any   |
	// 	|                 | special purpose calls. This is the recommended starting point for allow-listing  |
	// 	|                 | system calls for system services, as it contains what is typically needed by     |
	// 	|                 | system services, but excludes overly specific interfaces. For example, the       |
	// 	|                 | following APIs are excluded: "@clock", "@mount", "@swap", "@reboot".             |
	// 	| @timer          | System calls for scheduling operations by time (alarm, timer_create, …)          |
	// 	| @known          | All system calls defined by the kernel. This list is defined statically in       |
	// 	|                 | systemd based on a kernel version that was available when this systemd version   |
	// 	|                 | was released. It will become progressively more out-of-date as the kernel is     |
	// 	|                 | updated.                                                                         |
	// 	+-----------------+----------------------------------------------------------------------------------+
	//
	// Note, that as new system calls are added to the kernel, additional system calls might be added to the groups above. Contents
	// of the sets may also change between systemd versions. In addition, the list of system calls depends on the kernel version
	// and architecture for which systemd was compiled. Use systemd-analyze syscall-filter to list the actual list of system
	// calls in each filter.
	//
	// Generally, allow-listing system calls (rather than deny-listing) is the safer mode of operation. It is recommended to
	// enforce system call allow lists for all long-running system services. Specifically, the following lines are a relatively
	// safe basic choice for the majority of system services:
	//
	// 	[Service] SystemCallFilter=@system-service SystemCallErrorNumber=EPERM
	//
	// Note that various kernel system calls are defined redundantly: there are multiple system calls for executing the same
	// operation. For example, the pidfd_send_signal() system call may be used to execute operations similar to what can be done
	// with the older kill() system call, hence blocking the latter without the former only provides weak protection. Since new
	// system calls are added regularly to the kernel as development progresses, keeping system call deny lists comprehensive
	// requires constant work. It is thus recommended to use allow-listing instead, which offers the benefit that new system
	// calls are by default implicitly blocked until the allow list is updated.
	//
	// Also note that a number of system calls are required to be accessible for the dynamic linker to work. The dynamic linker is
	// required for running most regular programs (specifically: all dynamic ELF binaries, which is how most distributions
	// build packaged programs). This means that blocking these system calls (which include open(), openat() or mmap()) will
	// make most programs typically shipped with generic distributions unusable.
	//
	// It is recommended to combine the file system namespacing related options with SystemCallFilter=~@mount, in order to
	// prohibit the unit's processes to undo the mappings. Specifically these are the options PrivateTmp=, PrivateDevices=,
	// ProtectSystem=, ProtectHome=, ProtectKernelTunables=, ProtectControlGroups=, ProtectKernelLogs=, ProtectClock=,
	// ReadOnlyPaths=, InaccessiblePaths= and ReadWritePaths=.
	SystemCallFilter systemdconf.Value

	// Takes an "errno" error number (between 1 and 4095) or errno name such as EPERM, EACCES or EUCLEAN, to return when the system
	// call filter configured with SystemCallFilter= is triggered, instead of terminating the process immediately. See errno
	// for a full list of error codes. When this setting is not used, or when the empty string or the special setting "kill" is assigned,
	// the process will be terminated immediately when the filter is triggered.
	SystemCallErrorNumber systemdconf.Value

	// Takes a space-separated list of architecture identifiers to include in the system call filter. The known architecture
	// identifiers are the same as for ConditionArchitecture= described in systemd.unit, as well as x32, mips64-n32, mips64-le-n32,
	// and the special identifier native. The special identifier native implicitly maps to the native architecture of the system
	// (or more precisely: to the architecture the system manager is compiled for). If running in user mode, or in system mode,
	// but without the CAP_SYS_ADMIN capability (e.g. setting User=nobody), NoNewPrivileges=yes is implied. By default,
	// this option is set to the empty list, i.e. no filtering is applied.
	//
	// If this setting is used, processes of this unit will only be permitted to call native system calls, and system calls of the
	// specified architectures. For the purposes of this option, the x32 architecture is treated as including x86-64 system
	// calls. However, this setting still fulfills its purpose, as explained below, on x32.
	//
	// System call filtering is not equally effective on all architectures. For example, on x86 filtering of network socket-related
	// calls is not possible, due to ABI limitations — a limitation that x86-64 does not have, however. On systems supporting multiple
	// ABIs at the same time — such as x86/x86-64 — it is hence recommended to limit the set of permitted system call architectures
	// so that secondary ABIs may not be used to circumvent the restrictions applied to the native ABI of the system. In particular,
	// setting SystemCallArchitectures=native is a good choice for disabling non-native ABIs.
	//
	// System call architectures may also be restricted system-wide via the SystemCallArchitectures= option in the global
	// configuration. See systemd-system.conf for details.
	SystemCallArchitectures systemdconf.Value

	// Takes a space-separated list of system call names. If this setting is used, all system calls executed by the unit processes
	// for the listed ones will be logged. If the first character of the list is "~", the effect is inverted: all system calls except
	// the listed system calls will be logged. If running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability
	// (e.g. setting User=nobody), NoNewPrivileges=yes is implied. This feature makes use of the Secure Computing Mode 2 interfaces
	// of the kernel ('seccomp filtering') and is useful for auditing or setting up a minimal sandboxing environment. This option
	// may be specified more than once, in which case the filter masks are merged. If the empty string is assigned, the filter is
	// reset, all prior assignments will have no effect. This does not affect commands prefixed with "+".
	SystemCallLog systemdconf.Value

	// 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.
	//
	// The names of the variables can contain ASCII letters, digits, and the underscore character. Variable names cannot be empty
	// or start with a digit. In variable values, most characters are allowed, but non-printable characters are currently rejected.
	//
	// 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 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. Use LoadCredential= (see below) to pass data to unit processes securely.
	Environment systemdconf.Value

	// 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 (").
	//
	// C escapes are supported, but not most control characters. "\t" and "\n" can be used to insert tabs and newlines within EnvironmentFile=.
	//
	// 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. The files are read from the file system of the service manager, before any file system changes like
	// bind mounts take place).
	//
	// 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.
	EnvironmentFile systemdconf.Value

	// Pass environment variables set for the system service manager to executed processes. Takes a space-separated list of
	// variable names. This option may be specified more than once, in which case all listed variables will be passed. If the empty
	// string is assigned to this option, the list of environment variables to pass is reset, all prior assignments have no effect.
	// Variables specified that are not set for the system manager will not be passed and will be silently ignored. Note that this
	// option is only relevant for the system service manager, as system services by default do not automatically inherit any
	// environment variables set for the service manager itself. However, in case of the user service manager all environment
	// variables are passed to the executed processes anyway, hence this option is without effect for the user service manager.
	//
	// Variables set for invoked processes due to this setting are subject to being overridden by those configured with Environment=
	// or EnvironmentFile=.
	//
	// C escapes are supported, but not most control characters. "\t" and "\n" can be used to insert tabs and newlines within EnvironmentFile=.
	//
	// Example:
	//
	// 	PassEnvironment=VAR1 VAR2 VAR3
	//
	// passes three variables "VAR1", "VAR2", "VAR3" with the values set for those variables in PID1.
	//
	// See environ for details about environment variables.
	PassEnvironment systemdconf.Value

	// Explicitly unset environment variable assignments that would normally be passed from the service manager to invoked
	// processes of this unit. Takes a space-separated list of variable names or variable assignments. This option may be specified
	// more than once, in which case all listed variables/assignments will be unset. If the empty string is assigned to this option,
	// the list of environment variables/assignments to unset is reset. If a variable assignment is specified (that is: a variable
	// name, followed by "=", followed by its value), then any environment variable matching this precise assignment is removed.
	// If a variable name is specified (that is a variable name without any following "=" or value), then any assignment matching
	// the variable name, regardless of its value is removed. Note that the effect of UnsetEnvironment= is applied as final step
	// when the environment list passed to executed processes is compiled. That means it may undo assignments from any configuration
	// source, including assignments made through Environment= or EnvironmentFile=, inherited from the system manager's
	// global set of environment variables, inherited via PassEnvironment=, set by the service manager itself (such as $NOTIFY_SOCKET
	// and such), or set by a PAM module (in case PAMName= is used).
	//
	// See environ for details about environment variables.
	UnsetEnvironment systemdconf.Value

	// Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one of null, tty, tty-force,
	// tty-fail, data, file:path, socket or fd:name.
	//
	// If null is selected, standard input will be connected to /dev/null, i.e. all read attempts by the process will result in
	// immediate EOF.
	//
	// If tty is selected, standard input is connected to a TTY (as configured by TTYPath=, see below) and the executed process
	// becomes the controlling process of the terminal. If the terminal is already being controlled by another process, the executed
	// process waits until the current controlling process releases the terminal.
	//
	// tty-force is similar to tty, but the executed process is forcefully and immediately made the controlling process of the
	// terminal, potentially removing previous controlling processes from the terminal.
	//
	// tty-fail is similar to tty, but if the terminal already has a controlling process start-up of the executed process fails.
	//
	// The data option may be used to configure arbitrary textual or binary data to pass via standard input to the executed process.
	// The data to pass is configured via StandardInputText=/StandardInputData= (see below). Note that the actual file descriptor
	// type passed (memory file, regular file, UNIX pipe, …) might depend on the kernel and available privileges. In any case,
	// the file descriptor is read-only, and when read returns the specified data followed by EOF.
	//
	// The file:path option may be used to connect a specific file system object to standard input. An absolute path following
	// the ":" character is expected, which may refer to a regular file, a FIFO or special file. If an AF_UNIX socket in the file system
	// is specified, a stream socket is connected to it. The latter is useful for connecting standard input of processes to arbitrary
	// system services.
	//
	// The socket option is valid in socket-activated services only, and requires the relevant socket unit file (see systemd.socket
	// for details) to have Accept=yes set, or to specify a single socket only. If this option is set, standard input will be connected
	// to the socket the service was activated from, which is primarily useful for compatibility with daemons designed for use
	// with the traditional inetd socket activation daemon.
	//
	// The fd:name option connects standard input to a specific, named file descriptor provided by a socket unit. The name may
	// be specified as part of this option, following a ":" character (e.g. "fd:foobar"). If no name is specified, the name "stdin"
	// is implied (i.e. "fd" is equivalent to "fd:stdin"). At least one socket unit defining the specified name must be provided
	// via the Sockets= option, and the file descriptor name may differ from the name of its containing socket unit. If multiple
	// matches are found, the first one will be used. See FileDescriptorName= in systemd.socket for more details about named
	// file descriptors and their ordering.
	//
	// This setting defaults to null.
	StandardInput systemdconf.Value

	// Controls where file descriptor 1 (stdout) of the executed processes is connected to. Takes one of inherit, null, tty, journal,
	// kmsg, journal+console, kmsg+console, file:path, append:path, socket or fd:name.
	//
	// inherit duplicates the file descriptor of standard input for standard output.
	//
	// null connects standard output to /dev/null, i.e. everything written to it will be lost.
	//
	// tty connects standard output to a tty (as configured via TTYPath=, see below). If the TTY is used for output only, the executed
	// process will not become the controlling process of the terminal, and will not fail or wait for other processes to release
	// the terminal.
	//
	// journal connects standard output with the journal, which is accessible via journalctl. Note that everything that is written
	// to kmsg (see below) is implicitly stored in the journal as well, the specific option listed below is hence a superset of this
	// one. (Also note that any external, additional syslog daemons receive their log data from the journal, too, hence this is
	// the option to use when logging shall be processed with such a daemon.)
	//
	// kmsg connects standard output with the kernel log buffer which is accessible via dmesg, in addition to the journal. The
	// journal daemon might be configured to send all logs to kmsg anyway, in which case this option is no different from journal.
	//
	// journal+console and kmsg+console work in a similar way as the two options above but copy the output to the system console
	// as well.
	//
	// The file:path option may be used to connect a specific file system object to standard output. The semantics are similar
	// to the same option of StandardInput=, see above. If path refers to a regular file on the filesystem, it is opened (created
	// if it doesn't exist yet) for writing at the beginning of the file, but without truncating it. If standard input and output
	// are directed to the same file path, it is opened only once, for reading as well as writing and duplicated. This is particularly
	// useful when the specified path refers to an AF_UNIX socket in the file system, as in that case only a single stream connection
	// is created for both input and output.
	//
	// append:path is similar to file:path above, but it opens the file in append mode.
	//
	// socket connects standard output to a socket acquired via socket activation. The semantics are similar to the same option
	// of StandardInput=, see above.
	//
	// The fd:name option connects standard output to a specific, named file descriptor provided by a socket unit. A name may be
	// specified as part of this option, following a ":" character (e.g. "fd:foobar"). If no name is specified, the name "stdout"
	// is implied (i.e. "fd" is equivalent to "fd:stdout"). At least one socket unit defining the specified name must be provided
	// via the Sockets= option, and the file descriptor name may differ from the name of its containing socket unit. If multiple
	// matches are found, the first one will be used. See FileDescriptorName= in systemd.socket for more details about named
	// descriptors and their ordering.
	//
	// If the standard output (or error output, see below) of a unit is connected to the journal or the kernel log buffer, the unit
	// will implicitly gain a dependency of type After= on systemd-journald.socket (also see the "Implicit Dependencies" section
	// above). Also note that in this case stdout (or stderr, see below) will be an AF_UNIX stream socket, and not a pipe or FIFO that
	// can be re-opened. This means when executing shell scripts the construct echo "hello" > /dev/stderr for writing text to
	// stderr will not work. To mitigate this use the construct echo "hello" >&2 instead, which is mostly equivalent and avoids
	// this pitfall.
	//
	// This setting defaults to the value set with DefaultStandardOutput= in systemd-system.conf, which defaults to journal.
	// Note that setting this parameter might result in additional dependencies to be added to the unit (see above).
	StandardOutput systemdconf.Value

	// Controls where file descriptor 2 (stderr) of the executed processes is connected to. The available options are identical
	// to those of StandardOutput=, with some exceptions: if set to inherit the file descriptor used for standard output is duplicated
	// for standard error, while fd:name will use a default file descriptor name of "stderr".
	//
	// This setting defaults to the value set with DefaultStandardError= in systemd-system.conf, which defaults to inherit.
	// Note that setting this parameter might result in additional dependencies to be added to the unit (see above).
	StandardError systemdconf.Value

	// Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the executed processes. These settings
	// have no effect unless StandardInput= is set to data. Use this option to embed process input data directly in the unit file.
	//
	// StandardInputText= accepts arbitrary textual data. C-style escapes for special characters as well as the usual "%"-specifiers
	// are resolved. Each time this setting is used the specified text is appended to the per-unit data buffer, followed by a newline
	// character (thus every use appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines
	// configured with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an
	// empty line, add an additional "\n" to the end or beginning of a line).
	//
	// StandardInputData= accepts arbitrary binary data, encoded in Base64. No escape sequences or specifiers are resolved.
	// Any whitespace in the encoded version is ignored during decoding.
	//
	// Note that StandardInputText= and StandardInputData= operate on the same data buffer, and may be mixed in order to configure
	// both binary and textual data for the same input stream. The textual or binary data is joined strictly in the order the settings
	// appear in the unit file. Assigning an empty string to either will reset the data buffer.
	//
	// Please keep in mind that in order to maintain readability long unit file settings may be split into multiple lines, by suffixing
	// each line (except for the last) with a "\" character (see systemd.unit for details). This is particularly useful for large
	// data configured with these two options. Example:
	//
	// 	… StandardInput=data StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl
	// 	\ LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \ dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug
	// 	\ enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \ SWNrZSEK …
	StandardInputText systemdconf.Value

	// Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the executed processes. These settings
	// have no effect unless StandardInput= is set to data. Use this option to embed process input data directly in the unit file.
	//
	// StandardInputText= accepts arbitrary textual data. C-style escapes for special characters as well as the usual "%"-specifiers
	// are resolved. Each time this setting is used the specified text is appended to the per-unit data buffer, followed by a newline
	// character (thus every use appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines
	// configured with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an
	// empty line, add an additional "\n" to the end or beginning of a line).
	//
	// StandardInputData= accepts arbitrary binary data, encoded in Base64. No escape sequences or specifiers are resolved.
	// Any whitespace in the encoded version is ignored during decoding.
	//
	// Note that StandardInputText= and StandardInputData= operate on the same data buffer, and may be mixed in order to configure
	// both binary and textual data for the same input stream. The textual or binary data is joined strictly in the order the settings
	// appear in the unit file. Assigning an empty string to either will reset the data buffer.
	//
	// Please keep in mind that in order to maintain readability long unit file settings may be split into multiple lines, by suffixing
	// each line (except for the last) with a "\" character (see systemd.unit for details). This is particularly useful for large
	// data configured with these two options. Example:
	//
	// 	… StandardInput=data StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl
	// 	\ LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \ dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug
	// 	\ enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \ SWNrZSEK …
	StandardInputData systemdconf.Value

	// Configures filtering by log level of log messages generated by this unit. Takes a syslog log level, one of emerg (lowest
	// log level, only highest priority messages), alert, crit, err, warning, notice, info, debug (highest log level, also lowest
	// priority messages). See syslog for details. By default no filtering is applied (i.e. the default maximum log level is debug).
	// Use this option to configure the logging system to drop log messages of a specific service above the specified level. For
	// example, set LogLevelMax=info in order to turn off debug logging of a particularly chatty unit. Note that the configured
	// level is applied to any log messages written by any of the processes belonging to this unit, sent via any supported logging
	// protocol. The filtering is applied early in the logging pipeline, before any kind of further processing is done. Moreover,
	// messages which pass through this filter successfully might still be dropped by filters applied at a later stage in the logging
	// subsystem. For example, MaxLevelStore= configured in journald.conf might prohibit messages of higher log levels to
	// be stored on disk, even though the per-unit LogLevelMax= permitted it to be processed.
	LogLevelMax systemdconf.Value

	// Configures additional log metadata fields to include in all log records generated by processes associated with this unit.
	// This setting takes one or more journal field assignments in the format "FIELD=VALUE" separated by whitespace. See systemd.journal-fields
	// for details on the journal field concept. Even though the underlying journal implementation permits binary field values,
	// this setting accepts only valid UTF-8 values. To include space characters in a journal field value, enclose the assignment
	// in double quotes ("). The usual specifiers are expanded in all assignments (see below). Note that this setting is not only
	// useful for attaching additional metadata to log records of a unit, but given that all fields and values are indexed may also
	// be used to implement cross-unit log record matching. Assign an empty string to reset the list.
	LogExtraFields systemdconf.Value

	// Configures the rate limiting that is applied to messages generated by this unit. If, in the time interval defined by LogRateLimitIntervalSec=,
	// more messages than specified in LogRateLimitBurst= are logged by a service, all further messages within the interval
	// are dropped until the interval is over. A message about the number of dropped messages is generated. The time specification
	// for LogRateLimitIntervalSec= may be specified in the following units: "s", "min", "h", "ms", "us" (see systemd.time
	// for details). The default settings are set by RateLimitIntervalSec= and RateLimitBurst= configured in journald.conf.
	LogRateLimitIntervalSec systemdconf.Value

	// Configures the rate limiting that is applied to messages generated by this unit. If, in the time interval defined by LogRateLimitIntervalSec=,
	// more messages than specified in LogRateLimitBurst= are logged by a service, all further messages within the interval
	// are dropped until the interval is over. A message about the number of dropped messages is generated. The time specification
	// for LogRateLimitIntervalSec= may be specified in the following units: "s", "min", "h", "ms", "us" (see systemd.time
	// for details). The default settings are set by RateLimitIntervalSec= and RateLimitBurst= configured in journald.conf.
	LogRateLimitBurst systemdconf.Value

	// Run the unit's processes in the specified journal namespace. Expects a short user-defined string identifying the namespace.
	// If not used the processes of the service are run in the default journal namespace, i.e. their log stream is collected and
	// processed by systemd-journald.service. If this option is used any log data generated by processes of this unit (regardless
	// if via the syslog(), journal native logging or stdout/stderr logging) is collected and processed by an instance of the
	// systemd-journald@.service template unit, which manages the specified namespace. The log data is stored in a data store
	// independent from the default log namespace's data store. See systemd-journald.service for details about journal namespaces.
	//
	// Internally, journal namespaces are implemented through Linux mount namespacing and over-mounting the directory that
	// contains the relevant AF_UNIX sockets used for logging in the unit's mount namespace. Since mount namespaces are used
	// this setting disconnects propagation of mounts from the unit's processes to the host, similar to how ReadOnlyPaths= and
	// similar settings (see above) work. Journal namespaces may hence not be used for services that need to establish mount points
	// on the host.
	//
	// When this option is used the unit will automatically gain ordering and requirement dependencies on the two socket units
	// associated with the systemd-journald@.service instance so that they are automatically established prior to the unit
	// starting up. Note that when this option is used log output of this service does not appear in the regular journalctl output,
	// unless the --namespace= option is used.
	//
	// This option is only available for system services and is not supported for services running in per-user instances of the
	// service manager.
	LogNamespace systemdconf.Value

	// Sets the process name ("syslog tag") to prefix log lines sent to the logging system or the kernel log buffer with. If not set,
	// defaults to the process name of the executed process. This option is only useful when StandardOutput= or StandardError=
	// are set to journal or kmsg (or to the same settings in combination with +console) and only applies to log messages written
	// to stdout or stderr.
	SyslogIdentifier systemdconf.Value

	// Sets the syslog facility identifier to use when logging. One of kern, user, mail, daemon, auth, syslog, lpr, news, uucp,
	// cron, authpriv, ftp, local0, local1, local2, local3, local4, local5, local6 or local7. See syslog for details. This option
	// is only useful when StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings in combination
	// with +console), and only applies to log messages written to stdout or stderr. Defaults to daemon.
	SyslogFacility systemdconf.Value

	// The default syslog log level to use when logging to the logging system or the kernel log buffer. One of emerg, alert, crit,
	// err, warning, notice, info, debug. See syslog for details. This option is only useful when StandardOutput= or StandardError=
	// are set to journal or kmsg (or to the same settings in combination with +console), and only applies to log messages written
	// to stdout or stderr. Note that individual lines output by executed processes may be prefixed with a different log level
	// which can be used to override the default log level specified here. The interpretation of these prefixes may be disabled
	// with SyslogLevelPrefix=, see below. For details, see sd-daemon. Defaults to info.
	SyslogLevel systemdconf.Value

	// Takes a boolean argument. If true and StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings
	// in combination with +console), log lines written by the executed process that are prefixed with a log level will be processed
	// with this log level set but the prefix removed. If set to false, the interpretation of these prefixes is disabled and the
	// logged lines are passed on as-is. This only applies to log messages written to stdout or stderr. For details about this prefixing
	// see sd-daemon. Defaults to true.
	SyslogLevelPrefix systemdconf.Value

	// Sets the terminal device node to use if standard input, output, or error are connected to a TTY (see above). Defaults to /dev/console.
	TTYPath systemdconf.Value

	// Reset the terminal device specified with TTYPath= before and after execution. Defaults to "no".
	TTYReset systemdconf.Value

	// Disconnect all clients which have opened the terminal device specified with TTYPath= before and after execution. Defaults
	// to "no".
	TTYVHangup systemdconf.Value

	// If the terminal device specified with TTYPath= is a virtual console terminal, try to deallocate the TTY before and after
	// execution. This ensures that the screen and scrollback buffer is cleared. Defaults to "no".
	TTYVTDisallocate systemdconf.Value

	// Pass a credential to the unit. Credentials are limited-size binary or textual objects that may be passed to unit processes.
	// They are primarily used for passing cryptographic keys (both public and private) or certificates, user account information
	// or identity information from host to services. The data is accessible from the unit's processes via the file system, at
	// a read-only location that (if possible and permitted) is backed by non-swappable memory. The data is only accessible to
	// the user associated with the unit, via the User=/DynamicUser= settings (as well as the superuser). When available, the
	// location of credentials is exported as the $CREDENTIALS_DIRECTORY environment variable to the unit's processes.
	//
	// The LoadCredential= setting takes a textual ID to use as name for a credential plus a file system path. The ID must be a short
	// ASCII string suitable as filename in the filesystem, and may be chosen freely by the user. If the specified path is absolute
	// it is opened as regular file and the credential data is read from it. If the absolute path refers to an AF_UNIX stream socket
	// in the file system a connection is made to it (only once at unit start-up) and the credential data read from the connection,
	// providing an easy IPC integration point for dynamically providing credentials from other services. If the specified
	// path is not absolute and itself qualifies as valid credential identifier it is understood to refer to a credential that
	// the service manager itself received via the $CREDENTIALS_DIRECTORY environment variable, which may be used to propagate
	// credentials from an invoking environment (e.g. a container manager that invoked the service manager) into a service.
	// The contents of the file/socket may be arbitrary binary or textual data, including newline characters and NUL bytes. This
	// option may be used multiple times, each time defining an additional credential to pass to the unit.
	//
	// The credential files/IPC sockets must be accessible to the service manager, but don't have to be directly accessible to
	// the unit's processes: the credential data is read and copied into separate, read-only copies for the unit that are accessible
	// to appropriately privileged processes. This is particularly useful in combination with DynamicUser= as this way privileged
	// data can be made available to processes running under a dynamic UID (i.e. not a previously known one) without having to open
	// up access to all users.
	//
	// In order to reference the path a credential may be read from within a ExecStart= command line use "${CREDENTIALS_DIRECTORY}/mycred",
	// e.g. "ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred".
	//
	// Currently, an accumulated credential size limit of 1M bytes per unit is enforced.
	//
	// If referencing an AF_UNIX stream socket to connect to, the connection will originate from an abstract namespace socket,
	// that includes information about the unit and the credential ID in its socket name. Use getpeername to query this information.
	// The returned socket name is formatted as NUL RANDOM "/unit/" UNIT "/" ID, i.e. a NUL byte (as required for abstract namespace
	// socket names), followed by a random string (consisting of alphadecimal characters), followed by the literal string "/unit/",
	// followed by the requesting unit name, followed by the literal character "/", followed by the textual credential ID requested.
	// Example: "\0adf9d86b6eda275e/unit/foobar.service/credx" in case the credential "credx" is requested for a unit "foobar.service".
	// This functionality is useful for using a single listening socket to serve credentials to multiple consumers.
	LoadCredential systemdconf.Value

	// The SetCredential= setting is similar to LoadCredential= but accepts a literal value to use as data for the credential,
	// instead of a file system path to read the data from. Do not use this option for data that is supposed to be secret, as it is accessible
	// to unprivileged processes via IPC. It's only safe to use this for user IDs, public key material and similar non-sensitive
	// data. For everything else use LoadCredential=. In order to embed binary data into the credential data use C-style escaping
	// (i.e. "\n" to embed a newline, or "\x00" to embed a NUL byte).
	//
	// If a credential of the same ID is listed in both LoadCredential= and SetCredential=, the latter will act as default if the
	// former cannot be retrieved. In this case not being able to retrieve the credential from the path specified in LoadCredential=
	// is not considered fatal.
	SetCredential systemdconf.Value

	// Takes a four character identifier string for an utmp and wtmp entry for this service. This should only be set for services
	// such as getty implementations (such as agetty) where utmp/wtmp entries must be created and cleared before and after execution,
	// or for services that shall be executed as if they were run by a getty process (see below). If the configured string is longer
	// than four characters, it is truncated and the terminal four characters are used. This setting interprets %I style string
	// replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this service.
	UtmpIdentifier systemdconf.Value

	// Takes one of "init", "login" or "user". If UtmpIdentifier= is set, controls which type of utmp/wtmp entries for this service
	// are generated. This setting has no effect unless UtmpIdentifier= is set too. If "init" is set, only an INIT_PROCESS entry
	// is generated and the invoked process must implement a getty-compatible utmp/wtmp logic. If "login" is set, first an INIT_PROCESS
	// entry, followed by a LOGIN_PROCESS entry is generated. In this case, the invoked process must implement a login-compatible
	// utmp/wtmp logic. If "user" is set, first an INIT_PROCESS entry, then a LOGIN_PROCESS entry and finally a USER_PROCESS
	// entry is generated. In this case, the invoked process may be any process that is suitable to be run as session leader. Defaults
	// to "init".
	UtmpMode systemdconf.Value
}

ExecOptions represents systemd.exec — Execution environment configuration (see https://www.freedesktop.org/software/systemd/man/systemd.exec.html for details)

type InstallSection 

type InstallSection struct {
	systemdconf.Section

	// 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.
	Alias systemdconf.Value

	// 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 getty@.service will result
	// in systemctl enable getty@tty2.service creating a getty.target.wants/getty@tty2.service link to getty@.service.
	WantedBy systemdconf.Value

	// 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 getty@.service will result
	// in systemctl enable getty@tty2.service creating a getty.target.wants/getty@tty2.service link to getty@.service.
	RequiredBy systemdconf.Value

	// 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.
	Also systemdconf.Value

	// 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.
	DefaultInstance systemdconf.Value
}

InstallSection represents installation information for the unit (see https://www.freedesktop.org/software/systemd/man/systemd.unit.html#%5BInstall%5D%20Section%20Options for details)

type KillOptions 

type KillOptions struct {
	// Specifies how processes of this unit shall be killed. One of control-group, mixed, process, none.
	//
	// 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 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 process, only the main process itself is killed (not recommended!). If set to none, no process is killed
	// (strongly recommended against!). In this case, only the stop command will be executed on unit stop, but no process will
	// be killed otherwise. Processes remaining alive after stop are left in their control group and the control group continues
	// to exist after stop unless empty.
	//
	// Note that it is not recommended to set KillMode= to process or even none, as this allows processes to escape the service manager's
	// lifecycle and resource management, and to remain running even while their service is considered stopped and is assumed
	// to not consume any resources.
	//
	// Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal= or RestartKillSignal=).
	// 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 for more information.
	//
	// Defaults to control-group.
	KillMode systemdconf.Value

	// Specifies which signal to use when stopping 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. Defaults
	// to SIGTERM.
	//
	// Note that, right after sending the signal specified in this setting, systemd will always send SIGCONT, to ensure that even
	// suspended tasks can be terminated cleanly.
	KillSignal systemdconf.Value

	// Specifies which signal to use when restarting a service. The same as KillSignal= described above, with the exception that
	// this setting is used in a restart job. Not set by default, and the value of KillSignal= is used.
	RestartKillSignal systemdconf.Value

	// Specifies whether to send SIGHUP to remaining processes immediately after sending the signal configured with KillSignal=.
	// This is useful to indicate to shells and shell-like programs that their connection has been severed. Takes a boolean value.
	// Defaults to "no".
	SendSIGHUP systemdconf.Value

	// Specifies whether to send SIGKILL (or the signal specified by FinalKillSignal=) to remaining processes after a timeout,
	// if the normal shutdown procedure left processes of the service around. When disabled, a KillMode= of control-group or
	// mixed service will not restart if processes from prior services exist within the control group. Takes a boolean value.
	// Defaults to "yes".
	SendSIGKILL systemdconf.Value

	// Specifies which signal to send to remaining processes after a timeout if SendSIGKILL= is enabled. The signal configured
	// here should be one that is not typically caught and processed by services (SIGTERM is not suitable). Developers can find
	// it useful to use this to generate a coredump to troubleshoot why a service did not terminate upon receiving the initial SIGTERM
	// signal. This can be achieved by configuring LimitCORE= and setting FinalKillSignal= to either SIGQUIT or SIGABRT. Defaults
	// to SIGKILL.
	FinalKillSignal systemdconf.Value

	// Specifies which signal to use to terminate the service when the watchdog timeout expires (enabled through WatchdogSec=).
	// Defaults to SIGABRT.
	WatchdogSignal systemdconf.Value
}

KillOptions represents systemd.kill — Process killing procedure (see https://www.freedesktop.org/software/systemd/man/systemd.kill.html#Options for details)

type MountFile 

type MountFile struct {
	systemdconf.File

	Unit    UnitSection    // Generic information about the unit that is not dependent on the type of unit
	Mount   MountSection   // Information about the file system mount points it supervises
	Install InstallSection // Installation information for the unit
}

MountFile represents systemd.mount — Mount unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.mount.html for details)

type MountSection 

type MountSection struct {
	systemdconf.Section
	ExecOptions
	KillOptions
	ResourceControlOptions

	// Takes an absolute path of a device node, file or other resource to mount. See mount for details. If this refers to a device
	// node, a dependency on the respective device unit is automatically created. (See systemd.device for more information.)
	// This option is mandatory. Note that the usual specifier expansion is applied to this setting, literal percent characters
	// should hence be written as "%%". If this mount is a bind mount and the specified path does not exist yet it is created as directory.
	What systemdconf.Value

	// Takes an absolute path of a file or directory for the mount point; in particular, the destination cannot be a symbolic link.
	// If the mount point does not exist at the time of mounting, it is created as directory. This string must be reflected in the
	// unit filename. (See above.) This option is mandatory.
	Where systemdconf.Value

	// Takes a string for the file system type. See mount for details. This setting is optional.
	Type systemdconf.Value

	// Mount options to use when mounting. This takes a comma-separated list of options. This setting is optional. Note that the
	// usual specifier expansion is applied to this setting, literal percent characters should hence be written as "%%".
	Options systemdconf.Value

	// Takes a boolean argument. If true, parsing of the options specified in Options= is relaxed, and unknown mount options are
	// tolerated. This corresponds with mount's -s switch. Defaults to off.
	SloppyOptions systemdconf.Value

	// Takes a boolean argument. If true, detach the filesystem from the filesystem hierarchy at time of the unmount operation,
	// and clean up all references to the filesystem as soon as they are not busy anymore. This corresponds with umount's -l switch.
	// Defaults to off.
	LazyUnmount systemdconf.Value

	// Takes a boolean argument. If false, a mount point that shall be mounted read-write but cannot be mounted so is retried to
	// be mounted read-only. If true the operation will fail immediately after the read-write mount attempt did not succeed.
	// This corresponds with mount's -w switch. Defaults to off.
	ReadWriteOnly systemdconf.Value

	// Takes a boolean argument. If true, force an unmount (in case of an unreachable NFS system). This corresponds with umount's
	// -f switch. Defaults to off.
	ForceUnmount systemdconf.Value

	// Directories of mount points (and any parent directories) are automatically created if needed. This option specifies
	// the file system access mode used when creating these directories. Takes an access mode in octal notation. Defaults to 0755.
	DirectoryMode systemdconf.Value

	// Configures the time to wait for the mount command to finish. If a command does not exit within the configured time, the mount
	// will be considered failed and be shut down again. All commands still running will be terminated forcibly via SIGTERM, and
	// after another delay of this time with SIGKILL. (See KillMode= in systemd.kill.) Takes a unit-less value in seconds, or
	// a time span value such as "5min 20s". Pass 0 to disable the timeout logic. The default value is set from DefaultTimeoutStartSec=
	// option in systemd-system.conf.
	TimeoutSec systemdconf.Value
}

MountSection represents information about the file system mount points it supervises (see https://www.freedesktop.org/software/systemd/man/systemd.mount.html#Options for details)

type PathFile 

type PathFile struct {
	systemdconf.File

	Unit    UnitSection    // Generic information about the unit that is not dependent on the type of unit
	Path    PathSection    // Information about the path(s) it monitors
	Install InstallSection // Installation information for the unit
}

PathFile represents systemd.path — Path unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.path.html for details)

type PathSection 

type PathSection struct {
	systemdconf.Section

	// Defines paths to monitor for certain changes: PathExists= may be used to watch the mere existence of a file or directory.
	// If the file specified exists, the configured unit is activated. PathExistsGlob= works similar, but checks for the existence
	// of at least one file matching the globbing pattern specified. PathChanged= may be used to watch a file or directory and activate
	// the configured unit whenever it changes. It is not activated on every write to the watched file but it is activated if the
	// file which was open for writing gets closed. PathModified= is similar, but additionally it is activated also on simple
	// writes to the watched file. DirectoryNotEmpty= may be used to watch a directory and activate the configured unit whenever
	// it contains at least one file.
	//
	// The arguments of these directives must be absolute file system paths.
	//
	// Multiple directives may be combined, of the same and of different types, to watch multiple paths. If the empty string is
	// assigned to any of these options, the list of paths to watch is reset, and any prior assignments of these options will not
	// have any effect.
	//
	// If a path already exists (in case of PathExists= and PathExistsGlob=) or a directory already is not empty (in case of DirectoryNotEmpty=)
	// at the time the path unit is activated, then the configured unit is immediately activated as well. Something similar does
	// not apply to PathChanged= and PathModified=.
	//
	// If the path itself or any of the containing directories are not accessible, systemd will watch for permission changes and
	// notice that conditions are satisfied when permissions allow that.
	PathExists systemdconf.Value

	// Defines paths to monitor for certain changes: PathExists= may be used to watch the mere existence of a file or directory.
	// If the file specified exists, the configured unit is activated. PathExistsGlob= works similar, but checks for the existence
	// of at least one file matching the globbing pattern specified. PathChanged= may be used to watch a file or directory and activate
	// the configured unit whenever it changes. It is not activated on every write to the watched file but it is activated if the
	// file which was open for writing gets closed. PathModified= is similar, but additionally it is activated also on simple
	// writes to the watched file. DirectoryNotEmpty= may be used to watch a directory and activate the configured unit whenever
	// it contains at least one file.
	//
	// The arguments of these directives must be absolute file system paths.
	//
	// Multiple directives may be combined, of the same and of different types, to watch multiple paths. If the empty string is
	// assigned to any of these options, the list of paths to watch is reset, and any prior assignments of these options will not
	// have any effect.
	//
	// If a path already exists (in case of PathExists= and PathExistsGlob=) or a directory already is not empty (in case of DirectoryNotEmpty=)
	// at the time the path unit is activated, then the configured unit is immediately activated as well. Something similar does
	// not apply to PathChanged= and PathModified=.
	//
	// If the path itself or any of the containing directories are not accessible, systemd will watch for permission changes and
	// notice that conditions are satisfied when permissions allow that.
	PathExistsGlob systemdconf.Value

	// Defines paths to monitor for certain changes: PathExists= may be used to watch the mere existence of a file or directory.
	// If the file specified exists, the configured unit is activated. PathExistsGlob= works similar, but checks for the existence
	// of at least one file matching the globbing pattern specified. PathChanged= may be used to watch a file or directory and activate
	// the configured unit whenever it changes. It is not activated on every write to the watched file but it is activated if the
	// file which was open for writing gets closed. PathModified= is similar, but additionally it is activated also on simple
	// writes to the watched file. DirectoryNotEmpty= may be used to watch a directory and activate the configured unit whenever
	// it contains at least one file.
	//
	// The arguments of these directives must be absolute file system paths.
	//
	// Multiple directives may be combined, of the same and of different types, to watch multiple paths. If the empty string is
	// assigned to any of these options, the list of paths to watch is reset, and any prior assignments of these options will not
	// have any effect.
	//
	// If a path already exists (in case of PathExists= and PathExistsGlob=) or a directory already is not empty (in case of DirectoryNotEmpty=)
	// at the time the path unit is activated, then the configured unit is immediately activated as well. Something similar does
	// not apply to PathChanged= and PathModified=.
	//
	// If the path itself or any of the containing directories are not accessible, systemd will watch for permission changes and
	// notice that conditions are satisfied when permissions allow that.
	PathChanged systemdconf.Value

	// Defines paths to monitor for certain changes: PathExists= may be used to watch the mere existence of a file or directory.
	// If the file specified exists, the configured unit is activated. PathExistsGlob= works similar, but checks for the existence
	// of at least one file matching the globbing pattern specified. PathChanged= may be used to watch a file or directory and activate
	// the configured unit whenever it changes. It is not activated on every write to the watched file but it is activated if the
	// file which was open for writing gets closed. PathModified= is similar, but additionally it is activated also on simple
	// writes to the watched file. DirectoryNotEmpty= may be used to watch a directory and activate the configured unit whenever
	// it contains at least one file.
	//
	// The arguments of these directives must be absolute file system paths.
	//
	// Multiple directives may be combined, of the same and of different types, to watch multiple paths. If the empty string is
	// assigned to any of these options, the list of paths to watch is reset, and any prior assignments of these options will not
	// have any effect.
	//
	// If a path already exists (in case of PathExists= and PathExistsGlob=) or a directory already is not empty (in case of DirectoryNotEmpty=)
	// at the time the path unit is activated, then the configured unit is immediately activated as well. Something similar does
	// not apply to PathChanged= and PathModified=.
	//
	// If the path itself or any of the containing directories are not accessible, systemd will watch for permission changes and
	// notice that conditions are satisfied when permissions allow that.
	PathModified systemdconf.Value

	// Defines paths to monitor for certain changes: PathExists= may be used to watch the mere existence of a file or directory.
	// If the file specified exists, the configured unit is activated. PathExistsGlob= works similar, but checks for the existence
	// of at least one file matching the globbing pattern specified. PathChanged= may be used to watch a file or directory and activate
	// the configured unit whenever it changes. It is not activated on every write to the watched file but it is activated if the
	// file which was open for writing gets closed. PathModified= is similar, but additionally it is activated also on simple
	// writes to the watched file. DirectoryNotEmpty= may be used to watch a directory and activate the configured unit whenever
	// it contains at least one file.
	//
	// The arguments of these directives must be absolute file system paths.
	//
	// Multiple directives may be combined, of the same and of different types, to watch multiple paths. If the empty string is
	// assigned to any of these options, the list of paths to watch is reset, and any prior assignments of these options will not
	// have any effect.
	//
	// If a path already exists (in case of PathExists= and PathExistsGlob=) or a directory already is not empty (in case of DirectoryNotEmpty=)
	// at the time the path unit is activated, then the configured unit is immediately activated as well. Something similar does
	// not apply to PathChanged= and PathModified=.
	//
	// If the path itself or any of the containing directories are not accessible, systemd will watch for permission changes and
	// notice that conditions are satisfied when permissions allow that.
	DirectoryNotEmpty systemdconf.Value

	// The unit to activate when any of the configured paths changes. The argument is a unit name, whose suffix is not ".path". If
	// not specified, this value defaults to a service that has the same name as the path unit, except for the suffix. (See above.)
	// It is recommended that the unit name that is activated and the unit name of the path unit are named identical, except for the
	// suffix.
	Unit systemdconf.Value

	// Takes a boolean argument. If true, the directories to watch are created before watching. This option is ignored for PathExists=
	// settings. Defaults to false.
	MakeDirectory systemdconf.Value

	// If MakeDirectory= is enabled, use the mode specified here to create the directories in question. Takes an access mode in
	// octal notation. Defaults to 0755.
	DirectoryMode systemdconf.Value
}

PathSection represents information about the path(s) it monitors (see https://www.freedesktop.org/software/systemd/man/systemd.path.html#Options for details)

type ResourceControlOptions 

type ResourceControlOptions struct {
	// Turn on CPU usage accounting for this unit. Takes a boolean argument. Note that turning on CPU accounting for one unit will
	// also implicitly turn it on for all units contained in the same slice and for all its parent slices and the units contained
	// therein. The system default for this setting may be controlled with DefaultCPUAccounting= in systemd-system.conf.
	CPUAccounting systemdconf.Value

	// Assign the specified CPU time weight to the processes executed, if the unified control group hierarchy is used on the system.
	// These options take an integer value and control the "cpu.weight" control group attribute. The allowed range is 1 to 10000.
	// Defaults to 100. For details about this control group attribute, see Control Groups v2 and CFS Scheduler. The available
	// CPU time is split up among all units within one slice relative to their CPU time weight.
	//
	// While StartupCPUWeight= only applies to the startup phase of the system, CPUWeight= applies to normal runtime of the system,
	// and if the former is not set also to the startup phase. Using StartupCPUWeight= allows prioritizing specific services
	// at boot-up differently than during normal runtime.
	//
	// These settings replace CPUShares= and StartupCPUShares=.
	CPUWeight systemdconf.Value

	// Assign the specified CPU time weight to the processes executed, if the unified control group hierarchy is used on the system.
	// These options take an integer value and control the "cpu.weight" control group attribute. The allowed range is 1 to 10000.
	// Defaults to 100. For details about this control group attribute, see Control Groups v2 and CFS Scheduler. The available
	// CPU time is split up among all units within one slice relative to their CPU time weight.
	//
	// While StartupCPUWeight= only applies to the startup phase of the system, CPUWeight= applies to normal runtime of the system,
	// and if the former is not set also to the startup phase. Using StartupCPUWeight= allows prioritizing specific services
	// at boot-up differently than during normal runtime.
	//
	// These settings replace CPUShares= and StartupCPUShares=.
	StartupCPUWeight systemdconf.Value

	// Assign the specified CPU time quota to the processes executed. Takes a percentage value, suffixed with "%". The percentage
	// specifies how much CPU time the unit shall get at maximum, relative to the total CPU time available on one CPU. Use values
	// > 100% for allotting CPU time on more than one CPU. This controls the "cpu.max" attribute on the unified control group hierarchy
	// and "cpu.cfs_quota_us" on legacy. For details about these control group attributes, see Control Groups v2 and sched-bwc.txt.
	//
	// Example: CPUQuota=20% ensures that the executed processes will never get more than 20% CPU time on one CPU.
	CPUQuota systemdconf.Value

	// Assign the duration over which the CPU time quota specified by CPUQuota= is measured. Takes a time duration value in seconds,
	// with an optional suffix such as "ms" for milliseconds (or "s" for seconds.) The default setting is 100ms. The period is clamped
	// to the range supported by the kernel, which is [1ms, 1000ms]. Additionally, the period is adjusted up so that the quota interval
	// is also at least 1ms. Setting CPUQuotaPeriodSec= to an empty value resets it to the default.
	//
	// This controls the second field of "cpu.max" attribute on the unified control group hierarchy and "cpu.cfs_period_us"
	// on legacy. For details about these control group attributes, see Control Groups v2 and CFS Scheduler.
	//
	// Example: CPUQuotaPeriodSec=10ms to request that the CPU quota is measured in periods of 10ms.
	CPUQuotaPeriodSec systemdconf.Value

	// Restrict processes to be executed on specific CPUs. Takes a list of CPU indices or ranges separated by either whitespace
	// or commas. CPU ranges are specified by the lower and upper CPU indices separated by a dash.
	//
	// Setting AllowedCPUs= doesn't guarantee that all of the CPUs will be used by the processes as it may be limited by parent units.
	// The effective configuration is reported as EffectiveCPUs=.
	//
	// This setting is supported only with the unified control group hierarchy.
	AllowedCPUs systemdconf.Value

	// Restrict processes to be executed on specific memory NUMA nodes. Takes a list of memory NUMA nodes indices or ranges separated
	// by either whitespace or commas. Memory NUMA nodes ranges are specified by the lower and upper CPU indices separated by a
	// dash.
	//
	// Setting AllowedMemoryNodes= doesn't guarantee that all of the memory NUMA nodes will be used by the processes as it may
	// be limited by parent units. The effective configuration is reported as EffectiveMemoryNodes=.
	//
	// This setting is supported only with the unified control group hierarchy.
	AllowedMemoryNodes systemdconf.Value

	// Turn on process and kernel memory accounting for this unit. Takes a boolean argument. Note that turning on memory accounting
	// for one unit will also implicitly turn it on for all units contained in the same slice and for all its parent slices and the
	// units contained therein. The system default for this setting may be controlled with DefaultMemoryAccounting= in systemd-system.conf.
	MemoryAccounting systemdconf.Value

	// Specify the memory usage protection of the executed processes in this unit. When reclaiming memory, the unit is treated
	// as if it was using less memory resulting in memory to be preferentially reclaimed from unprotected units. Using MemoryLow=
	// results in a weaker protection where memory may still be reclaimed to avoid invoking the OOM killer in case there is no other
	// reclaimable memory.
	//
	// For a protection to be effective, it is generally required to set a corresponding allocation on all ancestors, which is
	// then distributed between children (with the exception of the root slice). Any MemoryMin= or MemoryLow= allocation that
	// is not explicitly distributed to specific children is used to create a shared protection for all children. As this is a shared
	// protection, the children will freely compete for the memory.
	//
	// Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes,
	// Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which
	// is taken relative to the installed physical memory on the system. If assigned the special value "infinity", all available
	// memory is protected, which may be useful in order to always inherit all of the protection afforded by ancestors. This controls
	// the "memory.min" or "memory.low" control group attribute. For details about this control group attribute, see Memory
	// Interface Files.
	//
	// This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.
	//
	// Units may have their children use a default "memory.min" or "memory.low" value by specifying DefaultMemoryMin= or DefaultMemoryLow=,
	// which has the same semantics as MemoryMin= and MemoryLow=. This setting does not affect "memory.min" or "memory.low"
	// in the unit itself. Using it to set a default child allocation is only useful on kernels older than 5.7, which do not support
	// the "memory_recursiveprot" cgroup2 mount option.
	MemoryMin systemdconf.Value

	// Specify the memory usage protection of the executed processes in this unit. When reclaiming memory, the unit is treated
	// as if it was using less memory resulting in memory to be preferentially reclaimed from unprotected units. Using MemoryLow=
	// results in a weaker protection where memory may still be reclaimed to avoid invoking the OOM killer in case there is no other
	// reclaimable memory.
	//
	// For a protection to be effective, it is generally required to set a corresponding allocation on all ancestors, which is
	// then distributed between children (with the exception of the root slice). Any MemoryMin= or MemoryLow= allocation that
	// is not explicitly distributed to specific children is used to create a shared protection for all children. As this is a shared
	// protection, the children will freely compete for the memory.
	//
	// Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes,
	// Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which
	// is taken relative to the installed physical memory on the system. If assigned the special value "infinity", all available
	// memory is protected, which may be useful in order to always inherit all of the protection afforded by ancestors. This controls
	// the "memory.min" or "memory.low" control group attribute. For details about this control group attribute, see Memory
	// Interface Files.
	//
	// This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.
	//
	// Units may have their children use a default "memory.min" or "memory.low" value by specifying DefaultMemoryMin= or DefaultMemoryLow=,
	// which has the same semantics as MemoryMin= and MemoryLow=. This setting does not affect "memory.min" or "memory.low"
	// in the unit itself. Using it to set a default child allocation is only useful on kernels older than 5.7, which do not support
	// the "memory_recursiveprot" cgroup2 mount option.
	MemoryLow systemdconf.Value

	// Specify the throttling limit on memory usage of the executed processes in this unit. Memory usage may go above the limit
	// if unavoidable, but the processes are heavily slowed down and memory is taken away aggressively in such cases. This is the
	// main mechanism to control memory usage of a unit.
	//
	// Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes,
	// Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which
	// is taken relative to the installed physical memory on the system. If assigned the special value "infinity", no memory throttling
	// is applied. This controls the "memory.high" control group attribute. For details about this control group attribute,
	// see Memory Interface Files.
	//
	// This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.
	MemoryHigh systemdconf.Value

	// Specify the absolute limit on memory usage of the executed processes in this unit. If memory usage cannot be contained under
	// the limit, out-of-memory killer is invoked inside the unit. It is recommended to use MemoryHigh= as the main control mechanism
	// and use MemoryMax= as the last line of defense.
	//
	// Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes,
	// Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which
	// is taken relative to the installed physical memory on the system. If assigned the special value "infinity", no memory limit
	// is applied. This controls the "memory.max" control group attribute. For details about this control group attribute,
	// see Memory Interface Files.
	//
	// This setting replaces MemoryLimit=.
	MemoryMax systemdconf.Value

	// Specify the absolute limit on swap usage of the executed processes in this unit.
	//
	// Takes a swap size in bytes. If the value is suffixed with K, M, G or T, the specified swap size is parsed as Kilobytes, Megabytes,
	// Gigabytes, or Terabytes (with the base 1024), respectively. If assigned the special value "infinity", no swap limit is
	// applied. This controls the "memory.swap.max" control group attribute. For details about this control group attribute,
	// see Memory Interface Files.
	//
	// This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.
	MemorySwapMax systemdconf.Value

	// Turn on task accounting for this unit. Takes a boolean argument. If enabled, the system manager will keep track of the number
	// of tasks in the unit. The number of tasks accounted this way includes both kernel threads and userspace processes, with
	// each thread counting individually. Note that turning on tasks accounting for one unit will also implicitly turn it on for
	// all units contained in the same slice and for all its parent slices and the units contained therein. The system default for
	// this setting may be controlled with DefaultTasksAccounting= in systemd-system.conf.
	TasksAccounting systemdconf.Value

	// 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 Process Number Controller.
	//
	// The system default for this setting may be controlled with DefaultTasksMax= in systemd-system.conf.
	TasksMax systemdconf.Value

	// Turn on Block I/O accounting for this unit, if the unified control group hierarchy is used on the system. Takes a boolean
	// argument. Note that turning on block I/O accounting for one unit will also implicitly turn it on for all units contained
	// in the same slice and all for its parent slices and the units contained therein. The system default for this setting may be
	// controlled with DefaultIOAccounting= in systemd-system.conf.
	//
	// This setting replaces BlockIOAccounting= and disables settings prefixed with BlockIO or StartupBlockIO.
	IOAccounting systemdconf.Value

	// Set the default overall block I/O weight for the executed processes, if the unified control group hierarchy is used on the
	// system. Takes a single weight value (between 1 and 10000) to set the default block I/O weight. This controls the "io.weight"
	// control group attribute, which defaults to 100. For details about this control group attribute, see IO Interface Files.
	// The available I/O bandwidth is split up among all units within one slice relative to their block I/O weight.
	//
	// While StartupIOWeight= only applies to the startup phase of the system, IOWeight= applies to the later runtime of the system,
	// and if the former is not set also to the startup phase. This allows prioritizing specific services at boot-up differently
	// than during runtime.
	//
	// These settings replace BlockIOWeight= and StartupBlockIOWeight= and disable settings prefixed with BlockIO or StartupBlockIO.
	IOWeight systemdconf.Value

	// Set the default overall block I/O weight for the executed processes, if the unified control group hierarchy is used on the
	// system. Takes a single weight value (between 1 and 10000) to set the default block I/O weight. This controls the "io.weight"
	// control group attribute, which defaults to 100. For details about this control group attribute, see IO Interface Files.
	// The available I/O bandwidth is split up among all units within one slice relative to their block I/O weight.
	//
	// While StartupIOWeight= only applies to the startup phase of the system, IOWeight= applies to the later runtime of the system,
	// and if the former is not set also to the startup phase. This allows prioritizing specific services at boot-up differently
	// than during runtime.
	//
	// These settings replace BlockIOWeight= and StartupBlockIOWeight= and disable settings prefixed with BlockIO or StartupBlockIO.
	StartupIOWeight systemdconf.Value

	// Set the per-device overall block I/O weight for the executed processes, if the unified control group hierarchy is used
	// on the system. Takes a space-separated pair of a file path and a weight value to specify the device specific weight value,
	// between 1 and 10000. (Example: "/dev/sda 1000"). The file path may be specified as path to a block device node or as any other
	// file, in which case the backing block device of the file system of the file is determined. This controls the "io.weight"
	// control group attribute, which defaults to 100. Use this option multiple times to set weights for multiple devices. For
	// details about this control group attribute, see IO Interface Files.
	//
	// This setting replaces BlockIODeviceWeight= and disables settings prefixed with BlockIO or StartupBlockIO.
	//
	// The specified device node should reference a block device that has an I/O scheduler associated, i.e. should not refer to
	// partition or loopback block devices, but to the originating, physical device. When a path to a regular file or directory
	// is specified it is attempted to discover the correct originating device backing the file system of the specified path.
	// This works correctly only for simpler cases, where the file system is directly placed on a partition or physical block device,
	// or where simple 1:1 encryption using dm-crypt/LUKS is used. This discovery does not cover complex storage and in particular
	// RAID and volume management storage devices.
	IODeviceWeight systemdconf.Value

	// Set the per-device overall block I/O bandwidth maximum limit for the executed processes, if the unified control group
	// hierarchy is used on the system. This limit is not work-conserving and the executed processes are not allowed to use more
	// even if the device has idle capacity. Takes a space-separated pair of a file path and a bandwidth value (in bytes per second)
	// to specify the device specific bandwidth. The file path may be a path to a block device node, or as any other file in which case
	// the backing block device of the file system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified
	// bandwidth is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
	// 5M"). This controls the "io.max" control group attributes. Use this option multiple times to set bandwidth limits for
	// multiple devices. For details about this control group attribute, see IO Interface Files.
	//
	// These settings replace BlockIOReadBandwidth= and BlockIOWriteBandwidth= and disable settings prefixed with BlockIO
	// or StartupBlockIO.
	//
	// Similar restrictions on block device discovery as for IODeviceWeight= apply, see above.
	IOReadBandwidthMax systemdconf.Value

	// Set the per-device overall block I/O bandwidth maximum limit for the executed processes, if the unified control group
	// hierarchy is used on the system. This limit is not work-conserving and the executed processes are not allowed to use more
	// even if the device has idle capacity. Takes a space-separated pair of a file path and a bandwidth value (in bytes per second)
	// to specify the device specific bandwidth. The file path may be a path to a block device node, or as any other file in which case
	// the backing block device of the file system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified
	// bandwidth is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
	// 5M"). This controls the "io.max" control group attributes. Use this option multiple times to set bandwidth limits for
	// multiple devices. For details about this control group attribute, see IO Interface Files.
	//
	// These settings replace BlockIOReadBandwidth= and BlockIOWriteBandwidth= and disable settings prefixed with BlockIO
	// or StartupBlockIO.
	//
	// Similar restrictions on block device discovery as for IODeviceWeight= apply, see above.
	IOWriteBandwidthMax systemdconf.Value

	// Set the per-device overall block I/O IOs-Per-Second maximum limit for the executed processes, if the unified control
	// group hierarchy is used on the system. This limit is not work-conserving and the executed processes are not allowed to use
	// more even if the device has idle capacity. Takes a space-separated pair of a file path and an IOPS value to specify the device
	// specific IOPS. The file path may be a path to a block device node, or as any other file in which case the backing block device
	// of the file system of the file is used. If the IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as KiloIOPS, MegaIOPS,
	// GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
	// 1K"). This controls the "io.max" control group attributes. Use this option multiple times to set IOPS limits for multiple
	// devices. For details about this control group attribute, see IO Interface Files.
	//
	// These settings are supported only if the unified control group hierarchy is used and disable settings prefixed with BlockIO
	// or StartupBlockIO.
	//
	// Similar restrictions on block device discovery as for IODeviceWeight= apply, see above.
	IOReadIOPSMax systemdconf.Value

	// Set the per-device overall block I/O IOs-Per-Second maximum limit for the executed processes, if the unified control
	// group hierarchy is used on the system. This limit is not work-conserving and the executed processes are not allowed to use
	// more even if the device has idle capacity. Takes a space-separated pair of a file path and an IOPS value to specify the device
	// specific IOPS. The file path may be a path to a block device node, or as any other file in which case the backing block device
	// of the file system of the file is used. If the IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as KiloIOPS, MegaIOPS,
	// GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
	// 1K"). This controls the "io.max" control group attributes. Use this option multiple times to set IOPS limits for multiple
	// devices. For details about this control group attribute, see IO Interface Files.
	//
	// These settings are supported only if the unified control group hierarchy is used and disable settings prefixed with BlockIO
	// or StartupBlockIO.
	//
	// Similar restrictions on block device discovery as for IODeviceWeight= apply, see above.
	IOWriteIOPSMax systemdconf.Value

	// Set the per-device average target I/O latency for the executed processes, if the unified control group hierarchy is used
	// on the system. Takes a file path and a timespan separated by a space to specify the device specific latency target. (Example:
	// "/dev/sda 25ms"). The file path may be specified as path to a block device node or as any other file, in which case the backing
	// block device of the file system of the file is determined. This controls the "io.latency" control group attribute. Use
	// this option multiple times to set latency target for multiple devices. For details about this control group attribute,
	// see IO Interface Files.
	//
	// Implies "IOAccounting=yes".
	//
	// These settings are supported only if the unified control group hierarchy is used.
	//
	// Similar restrictions on block device discovery as for IODeviceWeight= apply, see above.
	IODeviceLatencyTargetSec systemdconf.Value

	// Takes a boolean argument. If true, turns on IPv4 and IPv6 network traffic accounting for packets sent or received by the
	// unit. When this option is turned on, all IPv4 and IPv6 sockets created by any process of the unit are accounted for.
	//
	// When this option is used in socket units, it applies to all IPv4 and IPv6 sockets associated with it (including both listening
	// and connection sockets where this applies). Note that for socket-activated services, this configuration setting and
	// the accounting data of the service unit and the socket unit are kept separate, and displayed separately. No propagation
	// of the setting and the collected statistics is done, in either direction. Moreover, any traffic sent or received on any
	// of the socket unit's sockets is accounted to the socket unit — and never to the service unit it might have activated, even
	// if the socket is used by it.
	//
	// The system default for this setting may be controlled with DefaultIPAccounting= in systemd-system.conf.
	IPAccounting systemdconf.Value

	// Turn on network traffic filtering for IP packets sent and received over AF_INET and AF_INET6 sockets. Both directives
	// take a space separated list of IPv4 or IPv6 addresses, each optionally suffixed with an address prefix length in bits after
	// a "/" character. If the suffix is omitted, the address is considered a host address, i.e. the filter covers the whole address
	// (32 bits for IPv4, 128 bits for IPv6).
	//
	// The access lists configured with this option are applied to all sockets created by processes of this unit (or in the case
	// of socket units, associated with it). The lists are implicitly combined with any lists configured for any of the parent
	// slice units this unit might be a member of. By default both access lists are empty. Both ingress and egress traffic is filtered
	// by these settings. In case of ingress traffic the source IP address is checked against these access lists, in case of egress
	// traffic the destination IP address is checked. The following rules are applied in turn:
	//
	// Access is granted when the checked IP address matches an entry in the IPAddressAllow= list.
	//
	// Otherwise, access is denied when the checked IP address matches an entry in the IPAddressDeny= list.
	//
	// Otherwise, access is granted.
	//
	// In order to implement an allow-listing IP firewall, it is recommended to use a IPAddressDeny=any setting on an upper-level
	// slice unit (such as the root slice -.slice or the slice containing all system services system.slice – see systemd.special
	// for details on these slice units), plus individual per-service IPAddressAllow= lines permitting network access to relevant
	// services, and only them.
	//
	// Note that for socket-activated services, the IP access list configured on the socket unit applies to all sockets associated
	// with it directly, but not to any sockets created by the ultimately activated services for it. Conversely, the IP access
	// list configured for the service is not applied to any sockets passed into the service via socket activation. Thus, it is
	// usually a good idea to replicate the IP access lists on both the socket and the service unit. Nevertheless, it may make sense
	// to maintain one list more open and the other one more restricted, depending on the usecase.
	//
	// If these settings are used multiple times in the same unit the specified lists are combined. If an empty string is assigned
	// to these settings the specific access list is reset and all previous settings undone.
	//
	// In place of explicit IPv4 or IPv6 address and prefix length specifications a small set of symbolic names may be used. The
	// following names are defined:
	//
	// 	+---------------+--------------------------+--------------------------------+
	// 	| SYMBOLIC NAME |        DEFINITION        |            MEANING             |
	// 	+---------------+--------------------------+--------------------------------+
	// 	| any           | 0.0.0.0/0 ::/0           | Any host                       |
	// 	| localhost     | 127.0.0.0/8 ::1/128      | All addresses on the local     |
	// 	|               |                          | loopback                       |
	// 	| link-local    | 169.254.0.0/16 fe80::/64 | All link-local IP addresses    |
	// 	| multicast     | 224.0.0.0/4 ff00::/8     | All IP multicasting addresses  |
	// 	+---------------+--------------------------+--------------------------------+
	//
	// Note that these settings might not be supported on some systems (for example if eBPF control group support is not enabled
	// in the underlying kernel or container manager). These settings will have no effect in that case. If compatibility with
	// such systems is desired it is hence recommended to not exclusively rely on them for IP security.
	IPAddressAllow systemdconf.Value

	// Turn on network traffic filtering for IP packets sent and received over AF_INET and AF_INET6 sockets. Both directives
	// take a space separated list of IPv4 or IPv6 addresses, each optionally suffixed with an address prefix length in bits after
	// a "/" character. If the suffix is omitted, the address is considered a host address, i.e. the filter covers the whole address
	// (32 bits for IPv4, 128 bits for IPv6).
	//
	// The access lists configured with this option are applied to all sockets created by processes of this unit (or in the case
	// of socket units, associated with it). The lists are implicitly combined with any lists configured for any of the parent
	// slice units this unit might be a member of. By default both access lists are empty. Both ingress and egress traffic is filtered
	// by these settings. In case of ingress traffic the source IP address is checked against these access lists, in case of egress
	// traffic the destination IP address is checked. The following rules are applied in turn:
	//
	// Access is granted when the checked IP address matches an entry in the IPAddressAllow= list.
	//
	// Otherwise, access is denied when the checked IP address matches an entry in the IPAddressDeny= list.
	//
	// Otherwise, access is granted.
	//
	// In order to implement an allow-listing IP firewall, it is recommended to use a IPAddressDeny=any setting on an upper-level
	// slice unit (such as the root slice -.slice or the slice containing all system services system.slice – see systemd.special
	// for details on these slice units), plus individual per-service IPAddressAllow= lines permitting network access to relevant
	// services, and only them.
	//
	// Note that for socket-activated services, the IP access list configured on the socket unit applies to all sockets associated
	// with it directly, but not to any sockets created by the ultimately activated services for it. Conversely, the IP access
	// list configured for the service is not applied to any sockets passed into the service via socket activation. Thus, it is
	// usually a good idea to replicate the IP access lists on both the socket and the service unit. Nevertheless, it may make sense
	// to maintain one list more open and the other one more restricted, depending on the usecase.
	//
	// If these settings are used multiple times in the same unit the specified lists are combined. If an empty string is assigned
	// to these settings the specific access list is reset and all previous settings undone.
	//
	// In place of explicit IPv4 or IPv6 address and prefix length specifications a small set of symbolic names may be used. The
	// following names are defined:
	//
	// 	+---------------+--------------------------+--------------------------------+
	// 	| SYMBOLIC NAME |        DEFINITION        |            MEANING             |
	// 	+---------------+--------------------------+--------------------------------+
	// 	| any           | 0.0.0.0/0 ::/0           | Any host                       |
	// 	| localhost     | 127.0.0.0/8 ::1/128      | All addresses on the local     |
	// 	|               |                          | loopback                       |
	// 	| link-local    | 169.254.0.0/16 fe80::/64 | All link-local IP addresses    |
	// 	| multicast     | 224.0.0.0/4 ff00::/8     | All IP multicasting addresses  |
	// 	+---------------+--------------------------+--------------------------------+
	//
	// Note that these settings might not be supported on some systems (for example if eBPF control group support is not enabled
	// in the underlying kernel or container manager). These settings will have no effect in that case. If compatibility with
	// such systems is desired it is hence recommended to not exclusively rely on them for IP security.
	IPAddressDeny systemdconf.Value

	// Add custom network traffic filters implemented as BPF programs, applying to all IP packets sent and received over AF_INET
	// and AF_INET6 sockets. Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (/sys/fs/bpf/).
	//
	// The filters configured with this option are applied to all sockets created by processes of this unit (or in the case of socket
	// units, associated with it). The filters are loaded in addition to filters any of the parent slice units this unit might be
	// a member of as well as any IPAddressAllow= and IPAddressDeny= filters in any of these units. By default there are no filters
	// specified.
	//
	// If these settings are used multiple times in the same unit all the specified programs are attached. If an empty string is
	// assigned to these settings the program list is reset and all previous specified programs ignored.
	//
	// Note that for socket-activated services, the IP filter programs configured on the socket unit apply to all sockets associated
	// with it directly, but not to any sockets created by the ultimately activated services for it. Conversely, the IP filter
	// programs configured for the service are not applied to any sockets passed into the service via socket activation. Thus,
	// it is usually a good idea, to replicate the IP filter programs on both the socket and the service unit, however it often makes
	// sense to maintain one configuration more open and the other one more restricted, depending on the usecase.
	//
	// Note that these settings might not be supported on some systems (for example if eBPF control group support is not enabled
	// in the underlying kernel or container manager). These settings will fail the service in that case. If compatibility with
	// such systems is desired it is hence recommended to attach your filter manually (requires Delegate=yes) instead of using
	// this setting.
	IPIngressFilterPath systemdconf.Value

	// Add custom network traffic filters implemented as BPF programs, applying to all IP packets sent and received over AF_INET
	// and AF_INET6 sockets. Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (/sys/fs/bpf/).
	//
	// The filters configured with this option are applied to all sockets created by processes of this unit (or in the case of socket
	// units, associated with it). The filters are loaded in addition to filters any of the parent slice units this unit might be
	// a member of as well as any IPAddressAllow= and IPAddressDeny= filters in any of these units. By default there are no filters
	// specified.
	//
	// If these settings are used multiple times in the same unit all the specified programs are attached. If an empty string is
	// assigned to these settings the program list is reset and all previous specified programs ignored.
	//
	// Note that for socket-activated services, the IP filter programs configured on the socket unit apply to all sockets associated
	// with it directly, but not to any sockets created by the ultimately activated services for it. Conversely, the IP filter
	// programs configured for the service are not applied to any sockets passed into the service via socket activation. Thus,
	// it is usually a good idea, to replicate the IP filter programs on both the socket and the service unit, however it often makes
	// sense to maintain one configuration more open and the other one more restricted, depending on the usecase.
	//
	// Note that these settings might not be supported on some systems (for example if eBPF control group support is not enabled
	// in the underlying kernel or container manager). These settings will fail the service in that case. If compatibility with
	// such systems is desired it is hence recommended to attach your filter manually (requires Delegate=yes) instead of using
	// this setting.
	IPEgressFilterPath systemdconf.Value

	// Control access to specific device nodes by the executed processes. Takes two space-separated strings: a device node specifier
	// followed by a combination of r, w, m to control reading, writing, or creation of the specific device node(s) by the unit (mknod),
	// respectively. On cgroup-v1 this controls the "devices.allow" control group attribute. For details about this control
	// group attribute, see Device Whitelist Controller. In the unified cgroup hierarchy this functionality is implemented
	// using eBPF filtering.
	//
	// The device node specifier is either a path to a device node in the file system, starting with /dev/, or a string starting with
	// either "char-" or "block-" followed by a device group name, as listed in /proc/devices. The latter is useful to allow-list
	// all current and future devices belonging to a specific device group at once. The device group is matched according to filename
	// globbing rules, you may hence use the "*" and "?" wildcards. (Note that such globbing wildcards are not available for device
	// node path specifications!) In order to match device nodes by numeric major/minor, use device node paths in the /dev/char/
	// and /dev/block/ directories. However, matching devices by major/minor is generally not recommended as assignments
	// are neither stable nor portable between systems or different kernel versions.
	//
	// Examples: /dev/sda5 is a path to a device node, referring to an ATA or SCSI block device. "char-pts" and "char-alsa" are
	// specifiers for all pseudo TTYs and all ALSA sound devices, respectively. "char-cpu/*" is a specifier matching all CPU
	// related device groups.
	//
	// Note that allow lists defined this way should only reference device groups which are resolvable at the time the unit is started.
	// Any device groups not resolvable then are not added to the device allow list. In order to work around this limitation, consider
	// extending service units with a pair of After=modprobe@xyz.service and Wants=modprobe@xyz.service lines that load
	// the necessary kernel module implementing the device group if missing. Example:
	//
	// 	… [Unit] Wants=modprobe@loop.service After=modprobe@loop.service [Service] DeviceAllow=block-loop DeviceAllow=/dev/loop-control
	// 	…
	DeviceAllow systemdconf.Value

	// Control the policy for allowing device access:
	//
	// 	strict: means to only allow types of access that are explicitly specified.
	// 	closed: in addition, allows access to standard pseudo devices including /dev/null, /dev/zero, /dev/full, /dev/random,
	// 	and /dev/urandom.
	// 	auto: in addition, allows access to all devices if no explicit DeviceAllow= is present. This is the default.
	DevicePolicy systemdconf.Value

	// The name of the slice unit to place the unit in. Defaults to system.slice for all non-instantiated units of all unit types
	// (except for slice units themselves see below). Instance units are by default placed in a subslice of system.slice that
	// is named after the template name.
	//
	// This option may be used to arrange systemd units in a hierarchy of slices each of which might have resource settings applied.
	//
	// For units of type slice, the only accepted value for this setting is the parent slice. Since the name of a slice unit implies
	// the parent slice, it is hence redundant to ever set this parameter directly for slice units.
	//
	// Special care should be taken when relying on the default slice assignment in templated service units that have DefaultDependencies=no
	// set, see systemd.service, section "Default Dependencies" for details.
	Slice systemdconf.Value

	// 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, cpuset, io, blkio, memory, devices, pids, bpf-firewall,
	// and bpf-devices.
	//
	// 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.
	Delegate systemdconf.Value

	// Disables controllers from being enabled for a unit's children. If a controller listed is already in use in its subtree,
	// the controller will be removed from the subtree. This can be used to avoid child units being able to implicitly or explicitly
	// enable a controller. Defaults to not disabling any controllers.
	//
	// It may not be possible to successfully disable a controller if the unit or any child of the unit in question delegates controllers
	// to its children, as any delegated subtree of the cgroup hierarchy is unmanaged by systemd.
	//
	// Multiple controllers may be specified, separated by spaces. You may also pass DisableControllers= multiple times, in
	// which case each new instance adds another controller to disable. Passing DisableControllers= by itself with no controller
	// name present resets the disabled controller list.
	//
	// The following controller names may be specified: cpu, cpuacct, cpuset, io, blkio, memory, devices, pids, bpf-firewall,
	// and bpf-devices.
	DisableControllers systemdconf.Value

	// Specifies how systemd-oomd.service will act on this unit's cgroups. Defaults to auto.
	//
	// When set to kill, systemd-oomd will actively monitor this unit's cgroup metrics to decide whether it needs to act. If the
	// cgroup passes the limits set by oomd.conf or its overrides, systemd-oomd will send a SIGKILL to all of the processes under
	// the chosen candidate cgroup. Note that only descendant cgroups can be eligible candidates for killing; the unit that set
	// its property to kill is not a candidate (unless one of its ancestors set their property to kill). You can find more details
	// on candidates and kill behavior at systemd-oomd.service and oomd.conf. Setting either of these properties to kill will
	// also automatically acquire After= and Wants= dependencies on systemd-oomd.service unless DefaultDependencies=no.
	//
	// When set to auto, systemd-oomd will not actively use this cgroup's data for monitoring and detection. However, if an ancestor
	// cgroup has one of these properties set to kill, a unit with auto can still be an eligible candidate for systemd-oomd to act
	// on.
	ManagedOOMSwap systemdconf.Value

	// Specifies how systemd-oomd.service will act on this unit's cgroups. Defaults to auto.
	//
	// When set to kill, systemd-oomd will actively monitor this unit's cgroup metrics to decide whether it needs to act. If the
	// cgroup passes the limits set by oomd.conf or its overrides, systemd-oomd will send a SIGKILL to all of the processes under
	// the chosen candidate cgroup. Note that only descendant cgroups can be eligible candidates for killing; the unit that set
	// its property to kill is not a candidate (unless one of its ancestors set their property to kill). You can find more details
	// on candidates and kill behavior at systemd-oomd.service and oomd.conf. Setting either of these properties to kill will
	// also automatically acquire After= and Wants= dependencies on systemd-oomd.service unless DefaultDependencies=no.
	//
	// When set to auto, systemd-oomd will not actively use this cgroup's data for monitoring and detection. However, if an ancestor
	// cgroup has one of these properties set to kill, a unit with auto can still be an eligible candidate for systemd-oomd to act
	// on.
	ManagedOOMMemoryPressure systemdconf.Value

	// Overrides the default memory pressure limit set by oomd.conf for this unit (cgroup). Takes a percentage value between
	// 0% and 100%, inclusive. This property is ignored unless ManagedOOMMemoryPressure=kill. Defaults to 0%, which means
	// use the default set by oomd.conf.
	ManagedOOMMemoryPressureLimitPercent systemdconf.Value

	// Assign the specified CPU time share weight to the processes executed. These options take an integer value and control the
	// "cpu.shares" control group attribute. The allowed range is 2 to 262144. Defaults to 1024. For details about this control
	// group attribute, see CFS Scheduler. The available CPU time is split up among all units within one slice relative to their
	// CPU time share weight.
	//
	// While StartupCPUShares= only applies to the startup phase of the system, CPUShares= applies to normal runtime of the system,
	// and if the former is not set also to the startup phase. Using StartupCPUShares= allows prioritizing specific services
	// at boot-up differently than during normal runtime.
	//
	// Implies "CPUAccounting=yes".
	//
	// These settings are deprecated. Use CPUWeight= and StartupCPUWeight= instead.
	CPUShares systemdconf.Value

	// Assign the specified CPU time share weight to the processes executed. These options take an integer value and control the
	// "cpu.shares" control group attribute. The allowed range is 2 to 262144. Defaults to 1024. For details about this control
	// group attribute, see CFS Scheduler. The available CPU time is split up among all units within one slice relative to their
	// CPU time share weight.
	//
	// While StartupCPUShares= only applies to the startup phase of the system, CPUShares= applies to normal runtime of the system,
	// and if the former is not set also to the startup phase. Using StartupCPUShares= allows prioritizing specific services
	// at boot-up differently than during normal runtime.
	//
	// Implies "CPUAccounting=yes".
	//
	// These settings are deprecated. Use CPUWeight= and StartupCPUWeight= instead.
	StartupCPUShares systemdconf.Value

	// Specify the limit on maximum memory usage of the executed processes. The limit specifies how much process and kernel memory
	// can be used by tasks in this unit. Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory
	// size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively,
	// a percentage value may be specified, which is taken relative to the installed physical memory on the system. If assigned
	// the special value "infinity", no memory limit is applied. This controls the "memory.limit_in_bytes" control group attribute.
	// For details about this control group attribute, see Memory Resource Controller.
	//
	// Implies "MemoryAccounting=yes".
	//
	// This setting is deprecated. Use MemoryMax= instead.
	MemoryLimit systemdconf.Value

	// Turn on Block I/O accounting for this unit, if the legacy control group hierarchy is used on the system. Takes a boolean argument.
	// Note that turning on block I/O accounting for one unit will also implicitly turn it on for all units contained in the same
	// slice and all for its parent slices and the units contained therein. The system default for this setting may be controlled
	// with DefaultBlockIOAccounting= in systemd-system.conf.
	//
	// This setting is deprecated. Use IOAccounting= instead.
	BlockIOAccounting systemdconf.Value

	// Set the default overall block I/O weight for the executed processes, if the legacy control group hierarchy is used on the
	// system. Takes a single weight value (between 10 and 1000) to set the default block I/O weight. This controls the "blkio.weight"
	// control group attribute, which defaults to 500. For details about this control group attribute, see Block IO Controller.
	// The available I/O bandwidth is split up among all units within one slice relative to their block I/O weight.
	//
	// While StartupBlockIOWeight= only applies to the startup phase of the system, BlockIOWeight= applies to the later runtime
	// of the system, and if the former is not set also to the startup phase. This allows prioritizing specific services at boot-up
	// differently than during runtime.
	//
	// Implies "BlockIOAccounting=yes".
	//
	// These settings are deprecated. Use IOWeight= and StartupIOWeight= instead.
	BlockIOWeight systemdconf.Value

	// Set the default overall block I/O weight for the executed processes, if the legacy control group hierarchy is used on the
	// system. Takes a single weight value (between 10 and 1000) to set the default block I/O weight. This controls the "blkio.weight"
	// control group attribute, which defaults to 500. For details about this control group attribute, see Block IO Controller.
	// The available I/O bandwidth is split up among all units within one slice relative to their block I/O weight.
	//
	// While StartupBlockIOWeight= only applies to the startup phase of the system, BlockIOWeight= applies to the later runtime
	// of the system, and if the former is not set also to the startup phase. This allows prioritizing specific services at boot-up
	// differently than during runtime.
	//
	// Implies "BlockIOAccounting=yes".
	//
	// These settings are deprecated. Use IOWeight= and StartupIOWeight= instead.
	StartupBlockIOWeight systemdconf.Value

	// Set the per-device overall block I/O weight for the executed processes, if the legacy control group hierarchy is used on
	// the system. Takes a space-separated pair of a file path and a weight value to specify the device specific weight value, between
	// 10 and 1000. (Example: "/dev/sda 500"). The file path may be specified as path to a block device node or as any other file,
	// in which case the backing block device of the file system of the file is determined. This controls the "blkio.weight_device"
	// control group attribute, which defaults to 1000. Use this option multiple times to set weights for multiple devices. For
	// details about this control group attribute, see Block IO Controller.
	//
	// Implies "BlockIOAccounting=yes".
	//
	// This setting is deprecated. Use IODeviceWeight= instead.
	BlockIODeviceWeight systemdconf.Value

	// Set the per-device overall block I/O bandwidth limit for the executed processes, if the legacy control group hierarchy
	// is used on the system. Takes a space-separated pair of a file path and a bandwidth value (in bytes per second) to specify the
	// device specific bandwidth. The file path may be a path to a block device node, or as any other file in which case the backing
	// block device of the file system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth
	// is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
	// 5M"). This controls the "blkio.throttle.read_bps_device" and "blkio.throttle.write_bps_device" control group
	// attributes. Use this option multiple times to set bandwidth limits for multiple devices. For details about these control
	// group attributes, see Block IO Controller.
	//
	// Implies "BlockIOAccounting=yes".
	//
	// These settings are deprecated. Use IOReadBandwidthMax= and IOWriteBandwidthMax= instead.
	BlockIOReadBandwidth systemdconf.Value

	// Set the per-device overall block I/O bandwidth limit for the executed processes, if the legacy control group hierarchy
	// is used on the system. Takes a space-separated pair of a file path and a bandwidth value (in bytes per second) to specify the
	// device specific bandwidth. The file path may be a path to a block device node, or as any other file in which case the backing
	// block device of the file system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth
	// is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
	// 5M"). This controls the "blkio.throttle.read_bps_device" and "blkio.throttle.write_bps_device" control group
	// attributes. Use this option multiple times to set bandwidth limits for multiple devices. For details about these control
	// group attributes, see Block IO Controller.
	//
	// Implies "BlockIOAccounting=yes".
	//
	// These settings are deprecated. Use IOReadBandwidthMax= and IOWriteBandwidthMax= instead.
	BlockIOWriteBandwidth systemdconf.Value
}

ResourceControlOptions represents systemd.resource-control — Resource control unit settings (see https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html for details)

type ServiceFile 

type ServiceFile struct {
	systemdconf.File

	Unit    UnitSection    // Generic information about the unit that is not dependent on the type of unit
	Service ServiceSection // Information about the service and the process it supervises
	Install InstallSection // Installation information for the unit
}

ServiceFile represents systemd.service — Service unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.service.html for details)

type ServiceSection 

type ServiceSection struct {
	systemdconf.Section
	ExecOptions
	KillOptions
	ResourceControlOptions

	// 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 up 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. Note that if this option is used without RemainAfterExit=
	// the service will never enter "active" unit state, but directly transition from "activating" to "deactivating" or "dead"
	// since no process is configured that shall run continuously. In particular this means that after a service of this type ran
	// (and which has RemainAfterExit= not set) it will not show up as started afterwards, but as dead.
	//
	// 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. A service unit of this type is considered to be in the activating state until the specified bus name is acquired.
	// It is considered activated while the bus name is taken. Once the bus name is released the service is considered being no longer
	// functional which has the effect that the service manager attempts to terminate any remaining processes belonging to the
	// service. Services that drop their bus name as part of their shutdown logic thus should be prepared to receive a SIGTERM (or
	// whichever signal is configured in KillSignal=) as result.
	//
	// Behavior of notify is similar to exec; however, it is expected that the service sends a notification message via sd_notify
	// 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.
	//
	// 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.)
	Type systemdconf.Value

	// Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited.
	// Defaults to no.
	RemainAfterExit systemdconf.Value

	// 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.
	GuessMainPID systemdconf.Value

	// 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.
	PIDFile systemdconf.Value

	// Takes a D-Bus destination name that this service shall use. This option is mandatory for services where Type= is set to dbus.
	// It is recommended to always set this property if known to make it easy to map the service name to the D-Bus destination. In
	// particular, systemctl service-log-level/service-log-target verbs make use of this.
	BusName systemdconf.Value

	// 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.)
	//
	// For each of the specified commands, the first argument must be either an absolute path to an executable or a simple file name
	// without any slashes. Optionally, this filename may be prefixed with a number of special characters:
	//
	// 	+--------+----------------------------------------------------------------------------------+
	// 	| PREFIX |                                      EFFECT                                      |
	// 	+--------+----------------------------------------------------------------------------------+
	// 	| "@"    | If the executable path is prefixed with "@", the second specified token will be  |
	// 	|        | passed as "argv[0]" to the executed process (instead of the actual filename),    |
	// 	|        | followed by the further arguments specified.                                     |
	// 	| "-"    | If the executable path is prefixed with "-", an exit code of the command         |
	// 	|        | normally considered a failure (i.e. non-zero exit status or abnormal exit due to |
	// 	|        | signal) is recorded, but has no further effect and is considered equivalent to   |
	// 	|        | success.                                                                         |
	// 	| ":"    | If the executable path is prefixed with ":", environment variable substitution   |
	// 	|        | (as described by the "Command Lines" section below) is not applied.              |
	// 	| "+"    | If the executable path is prefixed with "+" then the process is executed with    |
	// 	|        | full privileges. In this mode privilege restrictions configured with User=,      |
	// 	|        | Group=, CapabilityBoundingSet= or the various file system namespacing options    |
	// 	|        | (such as PrivateDevices=, PrivateTmp=) are not applied to the invoked command    |
	// 	|        | line (but still affect any other ExecStart=, ExecStop=, … lines).                |
	// 	| "!"    | Similar to the "+" character discussed above this permits invoking command lines |
	// 	|        | with elevated privileges. However, unlike "+" the "!" character exclusively      |
	// 	|        | alters the effect of User=, Group= and SupplementaryGroups=, i.e. only the       |
	// 	|        | stanzas that affect user and group credentials. Note that this setting may be    |
	// 	|        | combined with DynamicUser=, in which case a dynamic user/group pair is allocated |
	// 	|        | before the command is invoked, but credential changing is left to the executed   |
	// 	|        | process itself.                                                                  |
	// 	| "!!"   | This prefix is very similar to "!", however it only has an effect on systems     |
	// 	|        | lacking support for ambient process capabilities, i.e. without support for       |
	// 	|        | AmbientCapabilities=. It's intended to be used for unit files that take benefit  |
	// 	|        | of ambient capabilities to run processes with minimal privileges wherever        |
	// 	|        | possible while remaining compatible with systems that lack ambient capabilities  |
	// 	|        | support. Note that when "!!" is used, and a system lacking ambient capability    |
	// 	|        | support is detected any configured SystemCallFilter= and CapabilityBoundingSet=  |
	// 	|        | stanzas are implicitly modified, in order to permit spawned processes to drop    |
	// 	|        | credentials and capabilities themselves, even if this is configured to not       |
	// 	|        | be allowed. Moreover, if this prefix is used and a system lacking ambient        |
	// 	|        | capability support is detected AmbientCapabilities= will be skipped and not be   |
	// 	|        | applied. On systems supporting ambient capabilities, "!!" has no effect and is   |
	// 	|        | redundant.                                                                       |
	// 	+--------+----------------------------------------------------------------------------------+
	//
	// "@", "-", ":", and one of "+"/"!"/"!!" may be used together and they can appear in any order. However, only one of "+", "!",
	// "!!" may be used at a time. Note that these prefixes are also supported for the other command line settings, i.e. ExecStartPre=,
	// ExecStartPost=, ExecReload=, ExecStop= and ExecStopPost=.
	//
	// If more than one command is specified, the commands are invoked sequentially in the order they appear in the unit file. If
	// one of the commands fails (and is not prefixed with "-"), other lines are not executed, and the unit is considered failed.
	//
	// Unless Type=forking is set, the process started via this command line will be considered the main process of the daemon.
	ExecStart systemdconf.Value

	// 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.
	//
	// Note that the execution of ExecStartPost= is taken into account for the purpose of Before=/After= ordering constraints.
	ExecStartPre systemdconf.Value

	// 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.
	//
	// Note that the execution of ExecStartPost= is taken into account for the purpose of Before=/After= ordering constraints.
	ExecStartPost systemdconf.Value

	// Optional commands that are executed before the command(s) in ExecStartPre=. Syntax is the same as for ExecStart=, except
	// that multiple command lines are allowed and the commands are executed one after the other, serially.
	//
	// The behavior is like an ExecStartPre= and condition check hybrid: when an ExecCondition= command exits with exit code
	// 1 through 254 (inclusive), the remaining commands are skipped and the unit is not marked as failed. However, if an ExecCondition=
	// command exits with 255 or abnormally (e.g. timeout, killed by a signal, etc.), the unit will be considered failed (and remaining
	// commands will be skipped). Exit code of 0 or those matching SuccessExitStatus= will continue execution to the next command(s).
	//
	// The same recommendations about not running long-running processes in ExecStartPre= also applies to ExecCondition=.
	// ExecCondition= will also run the commands in ExecStopPost=, as part of stopping the service, in the case of any non-zero
	// or abnormal exits, like the ones described above.
	ExecCondition systemdconf.Value

	// 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:
	//
	// 	ExecReload=kill -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. For example, dbus-broker uses the following:
	//
	// 	ExecReload=busctl call org.freedesktop.DBus \ /org/freedesktop/DBus org.freedesktop.DBus \ ReloadConfig
	ExecReload systemdconf.Value

	// 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). If this option is not specified, the process is terminated by sending the signal
	// specified in KillSignal= or RestartKillSignal= 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 sending some form of termination signal to it), but does not wait for it to do so. Since the remaining processes
	// of the services are killed according to KillMode= and KillSignal= or RestartKillSignal= 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.
	ExecStop systemdconf.Value

	// 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 for details.
	//
	// Note that the execution of ExecStopPost= is taken into account for the purpose of Before=/After= ordering constraints.
	ExecStopPost systemdconf.Value

	// 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.
	RestartSec systemdconf.Value

	// Configures the time to wait for start-up. If a daemon service does not signal start-up completion within the configured
	// time, the service will be considered failed and will be shut down again. The precise action depends on the TimeoutStartFailureMode=
	// option. 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).
	//
	// 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 extended
	// 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).
	TimeoutStartSec systemdconf.Value

	// 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. This default behavior can be changed by the TimeoutStopFailureMode=
	// option. 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). 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).
	//
	// 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 extended 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).
	TimeoutStopSec systemdconf.Value

	// This option configures the time to wait for the service to terminate when it was aborted due to a watchdog timeout (see WatchdogSec=).
	// If the service has a short TimeoutStopSec= this option can be used to give the system more time to write a core dump of the service.
	// Upon expiration the service will be forcibly terminated by SIGKILL (see KillMode= in systemd.kill). The core file will
	// be truncated in this case. Use TimeoutAbortSec= to set a sensible timeout for the core dumping per service that is large
	// enough to write all expected data while also being short enough to handle the service failure in due time.
	//
	// Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass an empty value to skip the dedicated watchdog
	// abort timeout handling and fall back TimeoutStopSec=. Pass "infinity" to disable the timeout logic. Defaults to DefaultTimeoutAbortSec=
	// from the manager configuration file (see systemd-system.conf).
	//
	// If a service of Type=notify handles SIGABRT itself (instead of relying on the kernel to write a core dump) it can send "EXTEND_TIMEOUT_USEC=…"
	// to extended the abort time beyond TimeoutAbortSec=. The first receipt of this message must occur before TimeoutAbortSec=
	// is exceeded, and once the abort time has extended beyond TimeoutAbortSec=, the service manager will allow the service
	// to continue to abort, provided the service repeats "EXTEND_TIMEOUT_USEC=…" within the interval specified, or terminates
	// itself (see sd_notify).
	TimeoutAbortSec systemdconf.Value

	// A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified value.
	TimeoutSec systemdconf.Value

	// These options configure the action that is taken in case a daemon service does not signal start-up within its configured
	// TimeoutStartSec=, respectively if it does not stop within TimeoutStopSec=. Takes one of terminate, abort and kill. Both
	// options default to terminate.
	//
	// If terminate is set the service will be gracefully terminated by sending the signal specified in KillSignal= (defaults
	// to SIGTERM, see systemd.kill). If the service does not terminate the FinalKillSignal= is sent after TimeoutStopSec=.
	// If abort is set, WatchdogSignal= is sent instead and TimeoutAbortSec= applies before sending FinalKillSignal=. This
	// setting may be used to analyze services that fail to start-up or shut-down intermittently. By using kill the service is
	// immediately terminated by sending FinalKillSignal= without any further timeout. This setting can be used to expedite
	// the shutdown of failing services.
	TimeoutStartFailureMode systemdconf.Value

	// These options configure the action that is taken in case a daemon service does not signal start-up within its configured
	// TimeoutStartSec=, respectively if it does not stop within TimeoutStopSec=. Takes one of terminate, abort and kill. Both
	// options default to terminate.
	//
	// If terminate is set the service will be gracefully terminated by sending the signal specified in KillSignal= (defaults
	// to SIGTERM, see systemd.kill). If the service does not terminate the FinalKillSignal= is sent after TimeoutStopSec=.
	// If abort is set, WatchdogSignal= is sent instead and TimeoutAbortSec= applies before sending FinalKillSignal=. This
	// setting may be used to analyze services that fail to start-up or shut-down intermittently. By using kill the service is
	// immediately terminated by sending FinalKillSignal= without any further timeout. This setting can be used to expedite
	// the shutdown of failing services.
	TimeoutStopFailureMode systemdconf.Value

	// Configures a maximum time for the service to run. If this is used and the service has been active for longer than the specified
	// time it is terminated and put into a failure state. Note that this setting does not have any effect on Type=oneshot services,
	// as they terminate immediately after activation completed. Pass "infinity" (the default) to configure no runtime limit.
	//
	// If a service of Type=notify sends "EXTEND_TIMEOUT_USEC=…", this may cause the runtime to be extended beyond RuntimeMaxSec=.
	// The first receipt of this message must occur before RuntimeMaxSec= is exceeded, and once the runtime has extended beyond
	// RuntimeMaxSec=, the service manager will allow the service to continue to run, provided the service repeats "EXTEND_TIMEOUT_USEC=…"
	// within the interval specified until the service shutdown is achieved by "STOPPING=1" (or termination). (see sd_notify).
	RuntimeMaxSec systemdconf.Value

	// Configures the watchdog timeout for a service. The watchdog is activated when the start-up is completed. The service must
	// call sd_notify regularly with "WATCHDOG=1" (i.e. the "keep-alive ping"). If the time between two such calls is larger
	// than the configured time, then the service is placed in a failed state and it will be terminated with SIGABRT (or the signal
	// specified by WatchdogSignal=). By setting Restart= to on-failure, on-watchdog, on-abnormal or always, the service
	// will be automatically restarted. The time configured here will be passed to the executed service process in the WATCHDOG_USEC=
	// environment variable. This allows daemons to automatically enable the keep-alive pinging logic if watchdog support
	// is enabled for the service. If this option is used, NotifyAccess= (see below) should be set to open access to the notification
	// socket provided by systemd. If NotifyAccess= is not set, it will be implicitly set to main. Defaults to 0, which disables
	// this feature. The service can check whether the service manager expects watchdog keep-alive notifications. See sd_watchdog_enabled
	// for details. sd_event_set_watchdog may be used to enable automatic watchdog notification support.
	WatchdogSec systemdconf.Value

	// 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.
	//
	// 	+------------------------------+----+--------+------------+------------+-------------+----------+-------------+
	// 	| RESTART SETTINGS/EXIT CAUSES | NO | ALWAYS | ON-SUCCESS | ON-FAILURE | ON-ABNORMAL | ON-ABORT | ON-WATCHDOG |
	// 	+------------------------------+----+--------+------------+------------+-------------+----------+-------------+
	// 	| Clean exit code or signal    |    | X      | X          |            |             |          |             |
	// 	| Unclean exit code            |    | X      |            | X          |             |          |             |
	// 	| Unclean signal               |    | X      |            | X          | X           | X        |             |
	// 	| Timeout                      |    | X      |            | X          | X           |          |             |
	// 	| Watchdog                     |    | X      |            | X          | X           |          | X           |
	// 	+------------------------------+----+--------+------------+------------+-------------+----------+-------------+
	//
	// As exceptions to the setting above, the service will not be restarted if the exit code or signal is specified in RestartPreventExitStatus=
	// (see below) or the service is stopped with systemctl stop or an equivalent operation. Also, the services will always be
	// restarted if the exit code or signal is specified in RestartForceExitStatus= (see below).
	//
	// Note that service restart is subject to unit start rate limiting configured with StartLimitIntervalSec= and StartLimitBurst=,
	// see systemd.unit for details. A restarted service enters the failed state only after the start limits are reached.
	//
	// Setting this to on-failure is the recommended choice for long-running services, in order to increase reliability by attempting
	// automatic recovery from errors. For services that shall be able to terminate on their own choice (and avoid immediate restarting),
	// on-abnormal is an alternative choice.
	Restart systemdconf.Value

	// 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 status 0 and the signals SIGHUP, SIGINT, SIGTERM, and SIGPIPE.
	// Exit status definitions can be numeric termination statuses, termination status names, or termination signal names,
	// separated by spaces. See the Process Exit Codes section in systemd.exec for a list of termination status names (for this
	// setting only the part without the "EXIT_" or "EX_" prefix should be used). See signal for a list of signal names.
	//
	// Note that this setting does not change the mapping between numeric exit statuses and their names, i.e. regardless how this
	// setting is used 0 will still be mapped to "SUCCESS" (and thus typically shown as "0/SUCCESS" in tool outputs) and 1 to "FAILURE"
	// (and thus typically shown as "1/FAILURE"), and so on. It only controls what happens as effect of these exit statuses, and
	// how it propagates to the state of the service as a whole.
	//
	// 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.
	//
	// 	SuccessExitStatus=TEMPFAIL 250 SIGKILL
	//
	// Exit status 75 (TEMPFAIL), 250, and the termination signal SIGKILL are considered clean service terminations.
	//
	// Note: systemd-analyze exit-status may be used to list exit statuses and translate between numerical status values and
	// names.
	SuccessExitStatus systemdconf.Value

	// Takes a list of exit status definitions that, when returned by the main service process, will prevent automatic service
	// restarts, regardless of the restart setting configured with Restart=. Exit status definitions can either be numeric
	// exit codes or termination signal names, and are separated by spaces. Defaults to the empty list, so that, by default, no
	// exit status is excluded from the configured restart logic. For example:
	//
	// 	RestartPreventExitStatus=1 6 SIGABRT
	//
	// ensures that exit codes 1 and 6 and the termination signal SIGABRT will not result in automatic service restarting. This
	// option may appear more than once, in which case the list of restart-preventing statuses is merged. If the empty string is
	// assigned to this option, the list is reset and all prior assignments of this option will have no effect.
	//
	// Note that this setting has no effect on processes configured via ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=
	// or ExecReload=, but only on the main service process, i.e. either the one invoked by ExecStart= or (depending on Type=,
	// PIDFile=, …) the otherwise configured main process.
	RestartPreventExitStatus systemdconf.Value

	// Takes 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=. The argument format is similar to RestartPreventExitStatus=.
	RestartForceExitStatus systemdconf.Value

	// Takes a boolean argument. If true, the root directory, as configured with the RootDirectory= option (see systemd.exec
	// for more information), is 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.
	RootDirectoryStartOnly systemdconf.Value

	// Set the O_NONBLOCK flag for all file descriptors passed via socket-based activation. If true, all file descriptors >=
	// 3 (i.e. all except stdin, stdout, stderr), excluding those passed in via the file descriptor storage logic (see FileDescriptorStoreMax=
	// for details), will have the O_NONBLOCK flag set and hence are in non-blocking mode. This option is only useful in conjunction
	// with a socket unit, as described in systemd.socket and has no effect on file descriptors which were previously saved in
	// the file-descriptor store for example. Defaults to false.
	NonBlocking systemdconf.Value

	// Controls access to the service status notification socket, as accessible via the sd_notify call. Takes one of none (the
	// default), main, exec or all. If none, no daemon status updates are accepted from the service processes, all status update
	// messages are ignored. If main, only service updates sent from the main process of the service are accepted. If exec, only
	// service updates sent from any of the main or control processes originating from one of the Exec*= commands are accepted.
	// If all, all services updates from all members of the service's control group are accepted. This option should be set to open
	// access to the notification socket when using Type=notify or WatchdogSec= (see above). If those options are used but NotifyAccess=
	// is not configured, it will be implicitly set to main.
	//
	// Note that sd_notify() notifications may be attributed to units correctly only if either the sending process is still around
	// at the time PID 1 processes the message, or if the sending process is explicitly runtime-tracked by the service manager.
	// The latter is the case if the service manager originally forked off the process, i.e. on all processes that match main or
	// exec. Conversely, if an auxiliary process of the unit sends an sd_notify() message and immediately exits, the service
	// manager might not be able to properly attribute the message to the unit, and thus will ignore it, even if NotifyAccess=all
	// is set for it.
	//
	// Hence, to eliminate all race conditions involving lookup of the client's unit and attribution of notifications to units
	// correctly, sd_notify_barrier() may be used. This call acts as a synchronization point and ensures all notifications
	// sent before this call have been picked up by the service manager when it returns successfully. Use of sd_notify_barrier()
	// is needed for clients which are not invoked by the service manager, otherwise this synchronization mechanism is unnecessary
	// for attribution of notifications to the unit.
	NotifyAccess systemdconf.Value

	// Specifies the name of the socket units this service shall inherit socket file descriptors from when the service is started.
	// Normally, it should not be necessary to use this setting, as all socket file descriptors whose unit shares the same name
	// as the service (subject to the different unit name suffix of course) are passed to the spawned process.
	//
	// Note that the same socket file descriptors may be passed to multiple processes simultaneously. Also note that a different
	// service may be activated on incoming socket traffic than the one which is ultimately configured to inherit the socket file
	// descriptors. Or, in other words: the Service= setting of .socket units does not have to match the inverse of the Sockets=
	// setting of the .service it refers to.
	//
	// This option may appear more than once, in which case the list of socket units is merged. Note that once set, clearing the list
	// of sockets again (for example, by assigning the empty string to this option) is not supported.
	Sockets systemdconf.Value

	// Configure how many file descriptors may be stored in the service manager for the service using sd_pid_notify_with_fds's
	// "FDSTORE=1" messages. This is useful for implementing services that can restart after an explicit request or a crash without
	// losing state. Any open sockets and other file descriptors which should not be closed during the restart may be stored this
	// way. Application state can either be serialized to a file in /run/, or better, stored in a memfd_create memory file descriptor.
	// Defaults to 0, i.e. no file descriptors may be stored in the service manager. All file descriptors passed to the service
	// manager from a specific service are passed back to the service's main process on the next service restart (see sd_listen_fds
	// for details about the precise protocol used and the order in which the file descriptors are passed). Any file descriptors
	// passed to the service manager are automatically closed when POLLHUP or POLLERR is seen on them, or when the service is fully
	// stopped and no job is queued or being executed for it. If this option is used, NotifyAccess= (see above) should be set to open
	// access to the notification socket provided by systemd. If NotifyAccess= is not set, it will be implicitly set to main.
	FileDescriptorStoreMax systemdconf.Value

	// Configure the location of a file containing USB FunctionFS descriptors, for implementation of USB gadget functions.
	// This is used only in conjunction with a socket unit with ListenUSBFunction= configured. The contents of this file are written
	// to the ep0 file after it is opened.
	USBFunctionDescriptors systemdconf.Value

	// Configure the location of a file containing USB FunctionFS strings. Behavior is similar to USBFunctionDescriptors=
	// above.
	USBFunctionStrings systemdconf.Value

	// Configure the Out-Of-Memory (OOM) killer policy. On Linux, when memory becomes scarce the kernel might decide to kill
	// a running process in order to free up memory and reduce memory pressure. This setting takes one of continue, stop or kill.
	// If set to continue and a process of the service is killed by the kernel's OOM killer this is logged but the service continues
	// running. If set to stop the event is logged but the service is terminated cleanly by the service manager. If set to kill and
	// one of the service's processes is killed by the OOM killer the kernel is instructed to kill all remaining processes of the
	// service, too. Defaults to the setting DefaultOOMPolicy= in systemd-system.conf is set to, except for services where
	// Delegate= is turned on, where it defaults to continue.
	//
	// Use the OOMScoreAdjust= setting to configure whether processes of the unit shall be considered preferred or less preferred
	// candidates for process termination by the Linux OOM killer logic. See systemd.exec for details.
	OOMPolicy systemdconf.Value
}

ServiceSection represents information about the service and the process it supervises (see https://www.freedesktop.org/software/systemd/man/systemd.service.html#Options for details)

type SliceFile 

type SliceFile struct {
	systemdconf.File

	Unit    UnitSection    // Generic information about the unit that is not dependent on the type of unit
	Install InstallSection // Installation information for the unit
}

SliceFile represents systemd.slice — Slice unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.slice.html for details)

type SocketFile 

type SocketFile struct {
	systemdconf.File

	Unit    UnitSection    // Generic information about the unit that is not dependent on the type of unit
	Socket  SocketSection  // Information about the socket or FIFO it supervises
	Install InstallSection // Installation information for the unit
}

SocketFile represents systemd.socket — Socket unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.socket.html for details)

type SocketSection 

type SocketSection struct {
	systemdconf.Section
	ExecOptions
	KillOptions
	ResourceControlOptions

	// Specifies an address to listen on for a stream (SOCK_STREAM), datagram (SOCK_DGRAM), or sequential packet (SOCK_SEQPACKET)
	// socket, respectively. The address can be written in various formats:
	//
	// If the address starts with a slash ("/"), it is read as file system socket in the AF_UNIX socket family.
	//
	// If the address starts with an at symbol ("@"), it is read as abstract namespace socket in the AF_UNIX family. The "@" is replaced
	// with a NUL character before binding. For details, see unix.
	//
	// If the address string is a single number, it is read as port number to listen on via IPv6. Depending on the value of BindIPv6Only=
	// (see below) this might result in the service being available via both IPv6 and IPv4 (default) or just via IPv6.
	//
	// If the address string is a string in the format "v.w.x.y:z", it is interpreted as IPv4 address v.w.x.y and port z.
	//
	// If the address string is a string in the format "[x]:y", it is interpreted as IPv6 address x and port y. An optional interface
	// scope (interface name or number) may be specified after a "%" symbol: "[x]:y%dev". Interface scopes are only useful with
	// link-local addresses, because the kernel ignores them in other cases. Note that if an address is specified as IPv6, it might
	// still make the service available via IPv4 too, depending on the BindIPv6Only= setting (see below).
	//
	// If the address string is a string in the format "vsock:x:y", it is read as CID x on a port y address in the AF_VSOCK family. The
	// CID is a unique 32-bit integer identifier in AF_VSOCK analogous to an IP address. Specifying the CID is optional, and may
	// be set to the empty string.
	//
	// Note that SOCK_SEQPACKET (i.e. ListenSequentialPacket=) is only available for AF_UNIX sockets. SOCK_STREAM (i.e.
	// ListenStream=) when used for IP sockets refers to TCP sockets, SOCK_DGRAM (i.e. ListenDatagram=) to UDP.
	//
	// These options may be specified more than once, in which case incoming traffic on any of the sockets will trigger service
	// activation, and all listed sockets will be passed to the service, regardless of whether there is incoming traffic on them
	// or not. If the empty string is assigned to any of these options, the list of addresses to listen on is reset, all prior uses
	// of any of these options will have no effect.
	//
	// It is also possible to have more than one socket unit for the same service when using Service=, and the service will receive
	// all the sockets configured in all the socket units. Sockets configured in one unit are passed in the order of configuration,
	// but no ordering between socket units is specified.
	//
	// If an IP address is used here, it is often desirable to listen on it before the interface it is configured on is up and running,
	// and even regardless of whether it will be up and running at any point. To deal with this, it is recommended to set the FreeBind=
	// option described below.
	ListenStream systemdconf.Value

	// Specifies an address to listen on for a stream (SOCK_STREAM), datagram (SOCK_DGRAM), or sequential packet (SOCK_SEQPACKET)
	// socket, respectively. The address can be written in various formats:
	//
	// If the address starts with a slash ("/"), it is read as file system socket in the AF_UNIX socket family.
	//
	// If the address starts with an at symbol ("@"), it is read as abstract namespace socket in the AF_UNIX family. The "@" is replaced
	// with a NUL character before binding. For details, see unix.
	//
	// If the address string is a single number, it is read as port number to listen on via IPv6. Depending on the value of BindIPv6Only=
	// (see below) this might result in the service being available via both IPv6 and IPv4 (default) or just via IPv6.
	//
	// If the address string is a string in the format "v.w.x.y:z", it is interpreted as IPv4 address v.w.x.y and port z.
	//
	// If the address string is a string in the format "[x]:y", it is interpreted as IPv6 address x and port y. An optional interface
	// scope (interface name or number) may be specified after a "%" symbol: "[x]:y%dev". Interface scopes are only useful with
	// link-local addresses, because the kernel ignores them in other cases. Note that if an address is specified as IPv6, it might
	// still make the service available via IPv4 too, depending on the BindIPv6Only= setting (see below).
	//
	// If the address string is a string in the format "vsock:x:y", it is read as CID x on a port y address in the AF_VSOCK family. The
	// CID is a unique 32-bit integer identifier in AF_VSOCK analogous to an IP address. Specifying the CID is optional, and may
	// be set to the empty string.
	//
	// Note that SOCK_SEQPACKET (i.e. ListenSequentialPacket=) is only available for AF_UNIX sockets. SOCK_STREAM (i.e.
	// ListenStream=) when used for IP sockets refers to TCP sockets, SOCK_DGRAM (i.e. ListenDatagram=) to UDP.
	//
	// These options may be specified more than once, in which case incoming traffic on any of the sockets will trigger service
	// activation, and all listed sockets will be passed to the service, regardless of whether there is incoming traffic on them
	// or not. If the empty string is assigned to any of these options, the list of addresses to listen on is reset, all prior uses
	// of any of these options will have no effect.
	//
	// It is also possible to have more than one socket unit for the same service when using Service=, and the service will receive
	// all the sockets configured in all the socket units. Sockets configured in one unit are passed in the order of configuration,
	// but no ordering between socket units is specified.
	//
	// If an IP address is used here, it is often desirable to listen on it before the interface it is configured on is up and running,
	// and even regardless of whether it will be up and running at any point. To deal with this, it is recommended to set the FreeBind=
	// option described below.
	ListenDatagram systemdconf.Value

	// Specifies an address to listen on for a stream (SOCK_STREAM), datagram (SOCK_DGRAM), or sequential packet (SOCK_SEQPACKET)
	// socket, respectively. The address can be written in various formats:
	//
	// If the address starts with a slash ("/"), it is read as file system socket in the AF_UNIX socket family.
	//
	// If the address starts with an at symbol ("@"), it is read as abstract namespace socket in the AF_UNIX family. The "@" is replaced
	// with a NUL character before binding. For details, see unix.
	//
	// If the address string is a single number, it is read as port number to listen on via IPv6. Depending on the value of BindIPv6Only=
	// (see below) this might result in the service being available via both IPv6 and IPv4 (default) or just via IPv6.
	//
	// If the address string is a string in the format "v.w.x.y:z", it is interpreted as IPv4 address v.w.x.y and port z.
	//
	// If the address string is a string in the format "[x]:y", it is interpreted as IPv6 address x and port y. An optional interface
	// scope (interface name or number) may be specified after a "%" symbol: "[x]:y%dev". Interface scopes are only useful with
	// link-local addresses, because the kernel ignores them in other cases. Note that if an address is specified as IPv6, it might
	// still make the service available via IPv4 too, depending on the BindIPv6Only= setting (see below).
	//
	// If the address string is a string in the format "vsock:x:y", it is read as CID x on a port y address in the AF_VSOCK family. The
	// CID is a unique 32-bit integer identifier in AF_VSOCK analogous to an IP address. Specifying the CID is optional, and may
	// be set to the empty string.
	//
	// Note that SOCK_SEQPACKET (i.e. ListenSequentialPacket=) is only available for AF_UNIX sockets. SOCK_STREAM (i.e.
	// ListenStream=) when used for IP sockets refers to TCP sockets, SOCK_DGRAM (i.e. ListenDatagram=) to UDP.
	//
	// These options may be specified more than once, in which case incoming traffic on any of the sockets will trigger service
	// activation, and all listed sockets will be passed to the service, regardless of whether there is incoming traffic on them
	// or not. If the empty string is assigned to any of these options, the list of addresses to listen on is reset, all prior uses
	// of any of these options will have no effect.
	//
	// It is also possible to have more than one socket unit for the same service when using Service=, and the service will receive
	// all the sockets configured in all the socket units. Sockets configured in one unit are passed in the order of configuration,
	// but no ordering between socket units is specified.
	//
	// If an IP address is used here, it is often desirable to listen on it before the interface it is configured on is up and running,
	// and even regardless of whether it will be up and running at any point. To deal with this, it is recommended to set the FreeBind=
	// option described below.
	ListenSequentialPacket systemdconf.Value

	// Specifies a file system FIFO (see fifo for details) to listen on. This expects an absolute file system path as argument.
	// Behavior otherwise is very similar to the ListenDatagram= directive above.
	ListenFIFO systemdconf.Value

	// Specifies a special file in the file system to listen on. This expects an absolute file system path as argument. Behavior
	// otherwise is very similar to the ListenFIFO= directive above. Use this to open character device nodes as well as special
	// files in /proc/ and /sys/.
	ListenSpecial systemdconf.Value

	// Specifies a Netlink family to create a socket for to listen on. This expects a short string referring to the AF_NETLINK family
	// name (such as audit or kobject-uevent) as argument, optionally suffixed by a whitespace followed by a multicast group
	// integer. Behavior otherwise is very similar to the ListenDatagram= directive above.
	ListenNetlink systemdconf.Value

	// Specifies a POSIX message queue name to listen on (see mq_overview for details). This expects a valid message queue name
	// (i.e. beginning with "/"). Behavior otherwise is very similar to the ListenFIFO= directive above. On Linux message queue
	// descriptors are actually file descriptors and can be inherited between processes.
	ListenMessageQueue systemdconf.Value

	// Specifies a USB FunctionFS endpoints location to listen on, for implementation of USB gadget functions. This expects
	// an absolute file system path of a FunctionFS mount point as the argument. Behavior otherwise is very similar to the ListenFIFO=
	// directive above. Use this to open the FunctionFS endpoint ep0. When using this option, the activated service has to have
	// the USBFunctionDescriptors= and USBFunctionStrings= options set.
	ListenUSBFunction systemdconf.Value

	// Takes one of udplite or sctp. The socket will use the UDP-Lite (IPPROTO_UDPLITE) or SCTP (IPPROTO_SCTP) protocol, respectively.
	SocketProtocol systemdconf.Value

	// Takes one of default, both or ipv6-only. Controls the IPV6_V6ONLY socket option (see ipv6 for details). If both, IPv6 sockets
	// bound will be accessible via both IPv4 and IPv6. If ipv6-only, they will be accessible via IPv6 only. If default (which is
	// the default, surprise!), the system wide default setting is used, as controlled by /proc/sys/net/ipv6/bindv6only,
	// which in turn defaults to the equivalent of both.
	BindIPv6Only systemdconf.Value

	// Takes an unsigned integer argument. Specifies the number of connections to queue that have not been accepted yet. This
	// setting matters only for stream and sequential packet sockets. See listen for details. Defaults to SOMAXCONN (128).
	Backlog systemdconf.Value

	// Specifies a network interface name to bind this socket to. If set, traffic will only be accepted from the specified network
	// interfaces. This controls the SO_BINDTODEVICE socket option (see socket for details). If this option is used, an implicit
	// dependency from this socket unit on the network interface device unit is created (see systemd.device). Note that setting
	// this parameter might result in additional dependencies to be added to the unit (see above).
	BindToDevice systemdconf.Value

	// Takes a UNIX user/group name. When specified, all AF_UNIX sockets and FIFO nodes in the file system are owned by the specified
	// user and group. If unset (the default), the nodes are owned by the root user/group (if run in system context) or the invoking
	// user/group (if run in user context). If only a user is specified but no group, then the group is derived from the user's default
	// group.
	SocketUser systemdconf.Value

	// Takes a UNIX user/group name. When specified, all AF_UNIX sockets and FIFO nodes in the file system are owned by the specified
	// user and group. If unset (the default), the nodes are owned by the root user/group (if run in system context) or the invoking
	// user/group (if run in user context). If only a user is specified but no group, then the group is derived from the user's default
	// group.
	SocketGroup systemdconf.Value

	// If listening on a file system socket or FIFO, this option specifies the file system access mode used when creating the file
	// node. Takes an access mode in octal notation. Defaults to 0666.
	SocketMode systemdconf.Value

	// If listening on a file system socket or FIFO, the parent directories are automatically created if needed. This option specifies
	// the file system access mode used when creating these directories. Takes an access mode in octal notation. Defaults to 0755.
	DirectoryMode systemdconf.Value

	// Takes a boolean argument. If yes, a service instance is spawned for each incoming connection and only the connection socket
	// is passed to it. If no, all listening sockets themselves are passed to the started service unit, and only one service unit
	// is spawned for all connections (also see above). This value is ignored for datagram sockets and FIFOs where a single service
	// unit unconditionally handles all incoming traffic. Defaults to no. For performance reasons, it is recommended to write
	// new daemons only in a way that is suitable for Accept=no. A daemon listening on an AF_UNIX socket may, but does not need to,
	// call close on the received socket before exiting. However, it must not unlink the socket from a file system. It should not
	// invoke shutdown on sockets it got with Accept=no, but it may do so for sockets it got with Accept=yes set. Setting Accept=yes
	// is mostly useful to allow daemons designed for usage with inetd to work unmodified with systemd socket activation.
	//
	// For IPv4 and IPv6 connections, the REMOTE_ADDR environment variable will contain the remote IP address, and REMOTE_PORT
	// will contain the remote port. This is the same as the format used by CGI. For SOCK_RAW, the port is the IP protocol.
	Accept systemdconf.Value

	// Takes a boolean argument. May only be used in conjunction with ListenSpecial=. If true, the specified special file is opened
	// in read-write mode, if false, in read-only mode. Defaults to false.
	Writable systemdconf.Value

	// Takes a boolean argument. May only be used when Accept=no. If yes, the socket's buffers are cleared after the triggered
	// service exited. This causes any pending data to be flushed and any pending incoming connections to be rejected. If no, the
	// socket's buffers won't be cleared, permitting the service to handle any pending connections after restart, which is the
	// usually expected behaviour. Defaults to no.
	FlushPending systemdconf.Value

	// The maximum number of connections to simultaneously run services instances for, when Accept=yes is set. If more concurrent
	// connections are coming in, they will be refused until at least one existing connection is terminated. This setting has
	// no effect on sockets configured with Accept=no or datagram sockets. Defaults to 64.
	MaxConnections systemdconf.Value

	// The maximum number of connections for a service per source IP address. This is very similar to the MaxConnections= directive
	// above. Disabled by default.
	MaxConnectionsPerSource systemdconf.Value

	// Takes a boolean argument. If true, the TCP/IP stack will send a keep alive message after 2h (depending on the configuration
	// of /proc/sys/net/ipv4/tcp_keepalive_time) for all TCP streams accepted on this socket. This controls the SO_KEEPALIVE
	// socket option (see socket and the TCP Keepalive HOWTO for details.) Defaults to false.
	KeepAlive systemdconf.Value

	// Takes time (in seconds) as argument. The connection needs to remain idle before TCP starts sending keepalive probes. This
	// controls the TCP_KEEPIDLE socket option (see socket and the TCP Keepalive HOWTO for details.) Defaults value is 7200 seconds
	// (2 hours).
	KeepAliveTimeSec systemdconf.Value

	// Takes time (in seconds) as argument between individual keepalive probes, if the socket option SO_KEEPALIVE has been set
	// on this socket. This controls the TCP_KEEPINTVL socket option (see socket and the TCP Keepalive HOWTO for details.) Defaults
	// value is 75 seconds.
	KeepAliveIntervalSec systemdconf.Value

	// Takes an integer as argument. It is the number of unacknowledged probes to send before considering the connection dead
	// and notifying the application layer. This controls the TCP_KEEPCNT socket option (see socket and the TCP Keepalive HOWTO
	// for details.) Defaults value is 9.
	KeepAliveProbes systemdconf.Value

	// Takes a boolean argument. TCP Nagle's algorithm works by combining a number of small outgoing messages, and sending them
	// all at once. This controls the TCP_NODELAY socket option (see tcp). Defaults to false.
	NoDelay systemdconf.Value

	// Takes an integer argument controlling the priority for all traffic sent from this socket. This controls the SO_PRIORITY
	// socket option (see socket for details.).
	Priority systemdconf.Value

	// Takes time (in seconds) as argument. If set, the listening process will be awakened only when data arrives on the socket,
	// and not immediately when connection is established. When this option is set, the TCP_DEFER_ACCEPT socket option will
	// be used (see tcp), and the kernel will ignore initial ACK packets without any data. The argument specifies the approximate
	// amount of time the kernel should wait for incoming data before falling back to the normal behavior of honoring empty ACK
	// packets. This option is beneficial for protocols where the client sends the data first (e.g. HTTP, in contrast to SMTP),
	// because the server process will not be woken up unnecessarily before it can take any action.
	//
	// If the client also uses the TCP_DEFER_ACCEPT option, the latency of the initial connection may be reduced, because the
	// kernel will send data in the final packet establishing the connection (the third packet in the "three-way handshake").
	//
	// Disabled by default.
	DeferAcceptSec systemdconf.Value

	// Takes an integer argument controlling the receive or send buffer sizes of this socket, respectively. This controls the
	// SO_RCVBUF and SO_SNDBUF socket options (see socket for details.). The usual suffixes K, M, G are supported and are understood
	// to the base of 1024.
	ReceiveBuffer systemdconf.Value

	// Takes an integer argument controlling the receive or send buffer sizes of this socket, respectively. This controls the
	// SO_RCVBUF and SO_SNDBUF socket options (see socket for details.). The usual suffixes K, M, G are supported and are understood
	// to the base of 1024.
	SendBuffer systemdconf.Value

	// Takes an integer argument controlling the IP Type-Of-Service field for packets generated from this socket. This controls
	// the IP_TOS socket option (see ip for details.). Either a numeric string or one of low-delay, throughput, reliability or
	// low-cost may be specified.
	IPTOS systemdconf.Value

	// Takes an integer argument controlling the IPv4 Time-To-Live/IPv6 Hop-Count field for packets generated from this socket.
	// This sets the IP_TTL/IPV6_UNICAST_HOPS socket options (see ip and ipv6 for details.)
	IPTTL systemdconf.Value

	// Takes an integer value. Controls the firewall mark of packets generated by this socket. This can be used in the firewall
	// logic to filter packets from this socket. This sets the SO_MARK socket option. See iptables for details.
	Mark systemdconf.Value

	// Takes a boolean value. If true, allows multiple binds to this TCP or UDP port. This controls the SO_REUSEPORT socket option.
	// See socket for details.
	ReusePort systemdconf.Value

	// Takes a string value. Controls the extended attributes "security.SMACK64", "security.SMACK64IPIN" and "security.SMACK64IPOUT",
	// respectively, i.e. the security label of the FIFO, or the security label for the incoming or outgoing connections of the
	// socket, respectively. See Smack.txt for details.
	SmackLabel systemdconf.Value

	// Takes a string value. Controls the extended attributes "security.SMACK64", "security.SMACK64IPIN" and "security.SMACK64IPOUT",
	// respectively, i.e. the security label of the FIFO, or the security label for the incoming or outgoing connections of the
	// socket, respectively. See Smack.txt for details.
	SmackLabelIPIn systemdconf.Value

	// Takes a string value. Controls the extended attributes "security.SMACK64", "security.SMACK64IPIN" and "security.SMACK64IPOUT",
	// respectively, i.e. the security label of the FIFO, or the security label for the incoming or outgoing connections of the
	// socket, respectively. See Smack.txt for details.
	SmackLabelIPOut systemdconf.Value

	// Takes a boolean argument. When true, systemd will attempt to figure out the SELinux label used for the instantiated service
	// from the information handed by the peer over the network. Note that only the security level is used from the information
	// provided by the peer. Other parts of the resulting SELinux context originate from either the target binary that is effectively
	// triggered by socket unit or from the value of the SELinuxContext= option. This configuration option only affects sockets
	// with Accept= mode set to "yes". Also note that this option is useful only when MLS/MCS SELinux policy is deployed. Defaults
	// to "false".
	SELinuxContextFromNet systemdconf.Value

	// Takes a size in bytes. Controls the pipe buffer size of FIFOs configured in this socket unit. See fcntl for details. The usual
	// suffixes K, M, G are supported and are understood to the base of 1024.
	PipeSize systemdconf.Value

	// These two settings take integer values and control the mq_maxmsg field or the mq_msgsize field, respectively, when creating
	// the message queue. Note that either none or both of these variables need to be set. See mq_setattr for details.
	MessageQueueMaxMessages systemdconf.Value

	// These two settings take integer values and control the mq_maxmsg field or the mq_msgsize field, respectively, when creating
	// the message queue. Note that either none or both of these variables need to be set. See mq_setattr for details.
	MessageQueueMessageSize systemdconf.Value

	// Takes a boolean value. Controls whether the socket can be bound to non-local IP addresses. This is useful to configure sockets
	// listening on specific IP addresses before those IP addresses are successfully configured on a network interface. This
	// sets the IP_FREEBIND/IPV6_FREEBIND socket option. For robustness reasons it is recommended to use this option whenever
	// you bind a socket to a specific IP address. Defaults to false.
	FreeBind systemdconf.Value

	// Takes a boolean value. Controls the IP_TRANSPARENT/IPV6_TRANSPARENT socket option. Defaults to false.
	Transparent systemdconf.Value

	// Takes a boolean value. This controls the SO_BROADCAST socket option, which allows broadcast datagrams to be sent from
	// this socket. Defaults to false.
	Broadcast systemdconf.Value

	// Takes a boolean value. This controls the SO_PASSCRED socket option, which allows AF_UNIX sockets to receive the credentials
	// of the sending process in an ancillary message. Defaults to false.
	PassCredentials systemdconf.Value

	// Takes a boolean value. This controls the SO_PASSSEC socket option, which allows AF_UNIX sockets to receive the security
	// context of the sending process in an ancillary message. Defaults to false.
	PassSecurity systemdconf.Value

	// Takes a boolean value. This controls the IP_PKTINFO, IPV6_RECVPKTINFO, NETLINK_PKTINFO or PACKET_AUXDATA socket options,
	// which enable reception of additional per-packet metadata as ancillary message, on AF_INET, AF_INET6, AF_UNIX and AF_PACKET
	// sockets. Defaults to false.
	PassPacketInfo systemdconf.Value

	// Takes one of "off", "us" (alias: "usec", "µs") or "ns" (alias: "nsec"). This controls the SO_TIMESTAMP or SO_TIMESTAMPNS
	// socket options, and enables whether ingress network traffic shall carry timestamping metadata. Defaults to off.
	Timestamping systemdconf.Value

	// Takes a string value. Controls the TCP congestion algorithm used by this socket. Should be one of "westwood", "veno", "cubic",
	// "lp" or any other available algorithm supported by the IP stack. This setting applies only to stream sockets.
	TCPCongestion systemdconf.Value

	// Takes one or more command lines, which are executed before or after the listening sockets/FIFOs are created and bound,
	// respectively. The first token of the command line must be an absolute filename, then followed by arguments for the process.
	// Multiple command lines may be specified following the same scheme as used for ExecStartPre= of service unit files.
	ExecStartPre systemdconf.Value

	// Takes one or more command lines, which are executed before or after the listening sockets/FIFOs are created and bound,
	// respectively. The first token of the command line must be an absolute filename, then followed by arguments for the process.
	// Multiple command lines may be specified following the same scheme as used for ExecStartPre= of service unit files.
	ExecStartPost systemdconf.Value

	// Additional commands that are executed before or after the listening sockets/FIFOs are closed and removed, respectively.
	// Multiple command lines may be specified following the same scheme as used for ExecStartPre= of service unit files.
	ExecStopPre systemdconf.Value

	// Additional commands that are executed before or after the listening sockets/FIFOs are closed and removed, respectively.
	// Multiple command lines may be specified following the same scheme as used for ExecStartPre= of service unit files.
	ExecStopPost systemdconf.Value

	// Configures the time to wait for the commands specified in ExecStartPre=, ExecStartPost=, ExecStopPre= and ExecStopPost=
	// to finish. If a command does not exit within the configured time, the socket will be considered failed and be shut down again.
	// All commands still running will be terminated forcibly via SIGTERM, and after another delay of this time with SIGKILL.
	// (See KillMode= in systemd.kill.) Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass "0" to
	// disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the manager configuration file (see systemd-system.conf).
	TimeoutSec systemdconf.Value

	// Specifies the service unit name to activate on incoming traffic. This setting is only allowed for sockets with Accept=no.
	// It defaults to the service that bears the same name as the socket (with the suffix replaced). In most cases, it should not
	// be necessary to use this option. Note that setting this parameter might result in additional dependencies to be added to
	// the unit (see above).
	Service systemdconf.Value

	// Takes a boolean argument. If enabled, any file nodes created by this socket unit are removed when it is stopped. This applies
	// to AF_UNIX sockets in the file system, POSIX message queues, FIFOs, as well as any symlinks to them configured with Symlinks=.
	// Normally, it should not be necessary to use this option, and is not recommended as services might continue to run after the
	// socket unit has been terminated and it should still be possible to communicate with them via their file system node. Defaults
	// to off.
	RemoveOnStop systemdconf.Value

	// Takes a list of file system paths. The specified paths will be created as symlinks to the AF_UNIX socket path or FIFO path
	// of this socket unit. If this setting is used, only one AF_UNIX socket in the file system or one FIFO may be configured for the
	// socket unit. Use this option to manage one or more symlinked alias names for a socket, binding their lifecycle together.
	// Note that if creation of a symlink fails this is not considered fatal for the socket unit, and the socket unit may still start.
	// If an empty string is assigned, the list of paths is reset. Defaults to an empty list.
	Symlinks systemdconf.Value

	// Assigns a name to all file descriptors this socket unit encapsulates. This is useful to help activated services identify
	// specific file descriptors, if multiple fds are passed. Services may use the sd_listen_fds_with_names call to acquire
	// the names configured for the received file descriptors. Names may contain any ASCII character, but must exclude control
	// characters and ":", and must be at most 255 characters in length. If this setting is not used, the file descriptor name defaults
	// to the name of the socket unit, including its .socket suffix.
	FileDescriptorName systemdconf.Value

	// Configures a limit on how often this socket unit my be activated within a specific time interval. The TriggerLimitIntervalSec=
	// may be used to configure the length of the time interval in the usual time units "us", "ms", "s", "min", "h", … and defaults
	// to 2s (See systemd.time for details on the various time units understood). The TriggerLimitBurst= setting takes a positive
	// integer value and specifies the number of permitted activations per time interval, and defaults to 200 for Accept=yes
	// sockets (thus by default permitting 200 activations per 2s), and 20 otherwise (20 activations per 2s). Set either to 0 to
	// disable any form of trigger rate limiting. If the limit is hit, the socket unit is placed into a failure mode, and will not
	// be connectible anymore until restarted. Note that this limit is enforced before the service activation is enqueued.
	TriggerLimitIntervalSec systemdconf.Value

	// Configures a limit on how often this socket unit my be activated within a specific time interval. The TriggerLimitIntervalSec=
	// may be used to configure the length of the time interval in the usual time units "us", "ms", "s", "min", "h", … and defaults
	// to 2s (See systemd.time for details on the various time units understood). The TriggerLimitBurst= setting takes a positive
	// integer value and specifies the number of permitted activations per time interval, and defaults to 200 for Accept=yes
	// sockets (thus by default permitting 200 activations per 2s), and 20 otherwise (20 activations per 2s). Set either to 0 to
	// disable any form of trigger rate limiting. If the limit is hit, the socket unit is placed into a failure mode, and will not
	// be connectible anymore until restarted. Note that this limit is enforced before the service activation is enqueued.
	TriggerLimitBurst systemdconf.Value
}

SocketSection represents information about the socket or FIFO it supervises (see https://www.freedesktop.org/software/systemd/man/systemd.socket.html#Options for details)

type SwapFile 

type SwapFile struct {
	systemdconf.File

	Unit    UnitSection    // Generic information about the unit that is not dependent on the type of unit
	Swap    SwapSection    // Information about the swap device it supervises
	Install InstallSection // Installation information for the unit
}

SwapFile represents systemd.swap — Swap unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.swap.html for details)

type SwapSection 

type SwapSection struct {
	systemdconf.Section
	ExecOptions
	KillOptions
	ResourceControlOptions

	// Takes an absolute path of a device node or file to use for paging. See swapon for details. If this refers to a device node, a
	// dependency on the respective device unit is automatically created. (See systemd.device for more information.) If this
	// refers to a file, a dependency on the respective mount unit is automatically created. (See systemd.mount for more information.)
	// This option is mandatory. Note that the usual specifier expansion is applied to this setting, literal percent characters
	// should hence be written as "%%".
	What systemdconf.Value

	// Swap priority to use when activating the swap device or file. This takes an integer. This setting is optional and ignored
	// when the priority is set by pri= in the Options= key.
	Priority systemdconf.Value

	// May contain an option string for the swap device. This may be used for controlling discard options among other functionality,
	// if the swap backing device supports the discard or trim operation. (See swapon for more information.) Note that the usual
	// specifier expansion is applied to this setting, literal percent characters should hence be written as "%%".
	Options systemdconf.Value

	// Configures the time to wait for the swapon command to finish. If a command does not exit within the configured time, the swap
	// will be considered failed and be shut down again. All commands still running will be terminated forcibly via SIGTERM, and
	// after another delay of this time with SIGKILL. (See KillMode= in systemd.kill.) Takes a unit-less value in seconds, or
	// a time span value such as "5min 20s". Pass "0" to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the
	// manager configuration file (see systemd-system.conf).
	TimeoutSec systemdconf.Value
}

SwapSection represents information about the swap device it supervises (see https://www.freedesktop.org/software/systemd/man/systemd.swap.html#Options for details)

type TargetFile 

type TargetFile struct {
	systemdconf.File

	Unit    UnitSection    // Generic information about the unit that is not dependent on the type of unit
	Install InstallSection // Installation information for the unit
}

TargetFile represents systemd.target — Target unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.target.html for details)

type TimerFile 

type TimerFile struct {
	systemdconf.File

	Unit    UnitSection    // Generic information about the unit that is not dependent on the type of unit
	Timer   TimerSection   // Information about the timer it defines
	Install InstallSection // Installation information for the unit
}

TimerFile represents systemd.timer — Timer unit configuration (see https://www.freedesktop.org/software/systemd/man/systemd.timer.html for details)

type TimerSection 

type TimerSection struct {
	systemdconf.Section

	// Defines monotonic timers relative to different starting points:
	//
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	|      SETTING       |                                     MEANING                                      |
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	| OnActiveSec=       | Defines a timer relative to the moment the timer unit itself is activated.       |
	// 	| OnBootSec=         | Defines a timer relative to when the machine was booted up. In containers,       |
	// 	|                    | for the system manager instance, this is mapped to OnStartupSec=, making both    |
	// 	|                    | equivalent.                                                                      |
	// 	| OnStartupSec=      | Defines a timer relative to when the service manager was first started. For      |
	// 	|                    | system timer units this is very similar to OnBootSec= as the system service      |
	// 	|                    | manager is generally started very early at boot. It's primarily useful when      |
	// 	|                    | configured in units running in the per-user service manager, as the user service |
	// 	|                    | manager is generally started on first login only, not already during boot.       |
	// 	| OnUnitActiveSec=   | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | activated.                                                                       |
	// 	| OnUnitInactiveSec= | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | deactivated.                                                                     |
	// 	+--------------------+----------------------------------------------------------------------------------+
	//
	// Multiple directives may be combined of the same and of different types, in which case the timer unit will trigger whenever
	// any of the specified timer expressions elapse. For example, by combining OnBootSec= and OnUnitActiveSec=, it is possible
	// to define a timer that elapses in regular intervals and activates a specific service each time. Moreover, both monotonic
	// time expressions and OnCalendar= calendar expressions may be combined in the same timer unit.
	//
	// The arguments to the directives are time spans configured in seconds. Example: "OnBootSec=50" means 50s after boot-up.
	// The argument may also include time units. Example: "OnBootSec=5h 30min" means 5 hours and 30 minutes after boot-up. For
	// details about the syntax of time spans, see systemd.time.
	//
	// If a timer configured with OnBootSec= or OnStartupSec= is already in the past when the timer unit is activated, it will immediately
	// elapse and the configured unit is started. This is not the case for timers defined in the other directives.
	//
	// These are monotonic timers, independent of wall-clock time and timezones. If the computer is temporarily suspended,
	// the monotonic clock generally pauses, too. Note that if WakeSystem= is used, a different monotonic clock is selected that
	// continues to advance while the system is suspended and thus can be used as the trigger to resume the system.
	//
	// If the empty string is assigned to any of these options, the list of timers is reset (both monotonic timers and OnCalendar=
	// timers, see below), and all prior assignments will have no effect.
	//
	// Note that timers do not necessarily expire at the precise time configured with these settings, as they are subject to the
	// AccuracySec= setting below.
	OnActiveSec systemdconf.Value

	// Defines monotonic timers relative to different starting points:
	//
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	|      SETTING       |                                     MEANING                                      |
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	| OnActiveSec=       | Defines a timer relative to the moment the timer unit itself is activated.       |
	// 	| OnBootSec=         | Defines a timer relative to when the machine was booted up. In containers,       |
	// 	|                    | for the system manager instance, this is mapped to OnStartupSec=, making both    |
	// 	|                    | equivalent.                                                                      |
	// 	| OnStartupSec=      | Defines a timer relative to when the service manager was first started. For      |
	// 	|                    | system timer units this is very similar to OnBootSec= as the system service      |
	// 	|                    | manager is generally started very early at boot. It's primarily useful when      |
	// 	|                    | configured in units running in the per-user service manager, as the user service |
	// 	|                    | manager is generally started on first login only, not already during boot.       |
	// 	| OnUnitActiveSec=   | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | activated.                                                                       |
	// 	| OnUnitInactiveSec= | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | deactivated.                                                                     |
	// 	+--------------------+----------------------------------------------------------------------------------+
	//
	// Multiple directives may be combined of the same and of different types, in which case the timer unit will trigger whenever
	// any of the specified timer expressions elapse. For example, by combining OnBootSec= and OnUnitActiveSec=, it is possible
	// to define a timer that elapses in regular intervals and activates a specific service each time. Moreover, both monotonic
	// time expressions and OnCalendar= calendar expressions may be combined in the same timer unit.
	//
	// The arguments to the directives are time spans configured in seconds. Example: "OnBootSec=50" means 50s after boot-up.
	// The argument may also include time units. Example: "OnBootSec=5h 30min" means 5 hours and 30 minutes after boot-up. For
	// details about the syntax of time spans, see systemd.time.
	//
	// If a timer configured with OnBootSec= or OnStartupSec= is already in the past when the timer unit is activated, it will immediately
	// elapse and the configured unit is started. This is not the case for timers defined in the other directives.
	//
	// These are monotonic timers, independent of wall-clock time and timezones. If the computer is temporarily suspended,
	// the monotonic clock generally pauses, too. Note that if WakeSystem= is used, a different monotonic clock is selected that
	// continues to advance while the system is suspended and thus can be used as the trigger to resume the system.
	//
	// If the empty string is assigned to any of these options, the list of timers is reset (both monotonic timers and OnCalendar=
	// timers, see below), and all prior assignments will have no effect.
	//
	// Note that timers do not necessarily expire at the precise time configured with these settings, as they are subject to the
	// AccuracySec= setting below.
	OnBootSec systemdconf.Value

	// Defines monotonic timers relative to different starting points:
	//
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	|      SETTING       |                                     MEANING                                      |
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	| OnActiveSec=       | Defines a timer relative to the moment the timer unit itself is activated.       |
	// 	| OnBootSec=         | Defines a timer relative to when the machine was booted up. In containers,       |
	// 	|                    | for the system manager instance, this is mapped to OnStartupSec=, making both    |
	// 	|                    | equivalent.                                                                      |
	// 	| OnStartupSec=      | Defines a timer relative to when the service manager was first started. For      |
	// 	|                    | system timer units this is very similar to OnBootSec= as the system service      |
	// 	|                    | manager is generally started very early at boot. It's primarily useful when      |
	// 	|                    | configured in units running in the per-user service manager, as the user service |
	// 	|                    | manager is generally started on first login only, not already during boot.       |
	// 	| OnUnitActiveSec=   | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | activated.                                                                       |
	// 	| OnUnitInactiveSec= | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | deactivated.                                                                     |
	// 	+--------------------+----------------------------------------------------------------------------------+
	//
	// Multiple directives may be combined of the same and of different types, in which case the timer unit will trigger whenever
	// any of the specified timer expressions elapse. For example, by combining OnBootSec= and OnUnitActiveSec=, it is possible
	// to define a timer that elapses in regular intervals and activates a specific service each time. Moreover, both monotonic
	// time expressions and OnCalendar= calendar expressions may be combined in the same timer unit.
	//
	// The arguments to the directives are time spans configured in seconds. Example: "OnBootSec=50" means 50s after boot-up.
	// The argument may also include time units. Example: "OnBootSec=5h 30min" means 5 hours and 30 minutes after boot-up. For
	// details about the syntax of time spans, see systemd.time.
	//
	// If a timer configured with OnBootSec= or OnStartupSec= is already in the past when the timer unit is activated, it will immediately
	// elapse and the configured unit is started. This is not the case for timers defined in the other directives.
	//
	// These are monotonic timers, independent of wall-clock time and timezones. If the computer is temporarily suspended,
	// the monotonic clock generally pauses, too. Note that if WakeSystem= is used, a different monotonic clock is selected that
	// continues to advance while the system is suspended and thus can be used as the trigger to resume the system.
	//
	// If the empty string is assigned to any of these options, the list of timers is reset (both monotonic timers and OnCalendar=
	// timers, see below), and all prior assignments will have no effect.
	//
	// Note that timers do not necessarily expire at the precise time configured with these settings, as they are subject to the
	// AccuracySec= setting below.
	OnStartupSec systemdconf.Value

	// Defines monotonic timers relative to different starting points:
	//
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	|      SETTING       |                                     MEANING                                      |
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	| OnActiveSec=       | Defines a timer relative to the moment the timer unit itself is activated.       |
	// 	| OnBootSec=         | Defines a timer relative to when the machine was booted up. In containers,       |
	// 	|                    | for the system manager instance, this is mapped to OnStartupSec=, making both    |
	// 	|                    | equivalent.                                                                      |
	// 	| OnStartupSec=      | Defines a timer relative to when the service manager was first started. For      |
	// 	|                    | system timer units this is very similar to OnBootSec= as the system service      |
	// 	|                    | manager is generally started very early at boot. It's primarily useful when      |
	// 	|                    | configured in units running in the per-user service manager, as the user service |
	// 	|                    | manager is generally started on first login only, not already during boot.       |
	// 	| OnUnitActiveSec=   | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | activated.                                                                       |
	// 	| OnUnitInactiveSec= | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | deactivated.                                                                     |
	// 	+--------------------+----------------------------------------------------------------------------------+
	//
	// Multiple directives may be combined of the same and of different types, in which case the timer unit will trigger whenever
	// any of the specified timer expressions elapse. For example, by combining OnBootSec= and OnUnitActiveSec=, it is possible
	// to define a timer that elapses in regular intervals and activates a specific service each time. Moreover, both monotonic
	// time expressions and OnCalendar= calendar expressions may be combined in the same timer unit.
	//
	// The arguments to the directives are time spans configured in seconds. Example: "OnBootSec=50" means 50s after boot-up.
	// The argument may also include time units. Example: "OnBootSec=5h 30min" means 5 hours and 30 minutes after boot-up. For
	// details about the syntax of time spans, see systemd.time.
	//
	// If a timer configured with OnBootSec= or OnStartupSec= is already in the past when the timer unit is activated, it will immediately
	// elapse and the configured unit is started. This is not the case for timers defined in the other directives.
	//
	// These are monotonic timers, independent of wall-clock time and timezones. If the computer is temporarily suspended,
	// the monotonic clock generally pauses, too. Note that if WakeSystem= is used, a different monotonic clock is selected that
	// continues to advance while the system is suspended and thus can be used as the trigger to resume the system.
	//
	// If the empty string is assigned to any of these options, the list of timers is reset (both monotonic timers and OnCalendar=
	// timers, see below), and all prior assignments will have no effect.
	//
	// Note that timers do not necessarily expire at the precise time configured with these settings, as they are subject to the
	// AccuracySec= setting below.
	OnUnitActiveSec systemdconf.Value

	// Defines monotonic timers relative to different starting points:
	//
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	|      SETTING       |                                     MEANING                                      |
	// 	+--------------------+----------------------------------------------------------------------------------+
	// 	| OnActiveSec=       | Defines a timer relative to the moment the timer unit itself is activated.       |
	// 	| OnBootSec=         | Defines a timer relative to when the machine was booted up. In containers,       |
	// 	|                    | for the system manager instance, this is mapped to OnStartupSec=, making both    |
	// 	|                    | equivalent.                                                                      |
	// 	| OnStartupSec=      | Defines a timer relative to when the service manager was first started. For      |
	// 	|                    | system timer units this is very similar to OnBootSec= as the system service      |
	// 	|                    | manager is generally started very early at boot. It's primarily useful when      |
	// 	|                    | configured in units running in the per-user service manager, as the user service |
	// 	|                    | manager is generally started on first login only, not already during boot.       |
	// 	| OnUnitActiveSec=   | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | activated.                                                                       |
	// 	| OnUnitInactiveSec= | Defines a timer relative to when the unit the timer unit is activating was last  |
	// 	|                    | deactivated.                                                                     |
	// 	+--------------------+----------------------------------------------------------------------------------+
	//
	// Multiple directives may be combined of the same and of different types, in which case the timer unit will trigger whenever
	// any of the specified timer expressions elapse. For example, by combining OnBootSec= and OnUnitActiveSec=, it is possible
	// to define a timer that elapses in regular intervals and activates a specific service each time. Moreover, both monotonic
	// time expressions and OnCalendar= calendar expressions may be combined in the same timer unit.
	//
	// The arguments to the directives are time spans configured in seconds. Example: "OnBootSec=50" means 50s after boot-up.
	// The argument may also include time units. Example: "OnBootSec=5h 30min" means 5 hours and 30 minutes after boot-up. For
	// details about the syntax of time spans, see systemd.time.
	//
	// If a timer configured with OnBootSec= or OnStartupSec= is already in the past when the timer unit is activated, it will immediately
	// elapse and the configured unit is started. This is not the case for timers defined in the other directives.
	//
	// These are monotonic timers, independent of wall-clock time and timezones. If the computer is temporarily suspended,
	// the monotonic clock generally pauses, too. Note that if WakeSystem= is used, a different monotonic clock is selected that
	// continues to advance while the system is suspended and thus can be used as the trigger to resume the system.
	//
	// If the empty string is assigned to any of these options, the list of timers is reset (both monotonic timers and OnCalendar=
	// timers, see below), and all prior assignments will have no effect.
	//
	// Note that timers do not necessarily expire at the precise time configured with these settings, as they are subject to the
	// AccuracySec= setting below.
	OnUnitInactiveSec systemdconf.Value

	// Defines realtime (i.e. wallclock) timers with calendar event expressions. See systemd.time for more information on
	// the syntax of calendar event expressions. Otherwise, the semantics are similar to OnActiveSec= and related settings.
	//
	// Note that timers do not necessarily expire at the precise time configured with this setting, as it is subject to the AccuracySec=
	// setting below.
	//
	// May be specified more than once, in which case the timer unit will trigger whenever any of the specified expressions elapse.
	// Moreover calendar timers and monotonic timers (see above) may be combined within the same timer unit.
	//
	// If the empty string is assigned to any of these options, the list of timers is reset (both OnCalendar= timers and monotonic
	// timers, see above), and all prior assignments will have no effect.
	OnCalendar systemdconf.Value

	// Specify the accuracy the timer shall elapse with. Defaults to 1min. The timer is scheduled to elapse within a time window
	// starting with the time specified in OnCalendar=, OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec= or OnUnitInactiveSec=
	// and ending the time configured with AccuracySec= later. Within this time window, the expiry time will be placed at a host-specific,
	// randomized, but stable position that is synchronized between all local timer units. This is done in order to optimize power
	// consumption to suppress unnecessary CPU wake-ups. To get best accuracy, set this option to 1us. Note that the timer is still
	// subject to the timer slack configured via systemd-system.conf's TimerSlackNSec= setting. See prctl for details. To
	// optimize power consumption, make sure to set this value as high as possible and as low as necessary.
	//
	// Note that this setting is primarily a power saving option that allows coalescing CPU wake-ups. It should not be confused
	// with RandomizedDelaySec= (see below) which adds a random value to the time the timer shall elapse next and whose purpose
	// is the opposite: to stretch elapsing of timer events over a longer period to reduce workload spikes. For further details
	// and explanations and how both settings play together, see below.
	AccuracySec systemdconf.Value

	// Delay the timer by a randomly selected, evenly distributed amount of time between 0 and the specified time value. Defaults
	// to 0, indicating that no randomized delay shall be applied. Each timer unit will determine this delay randomly before each
	// iteration, and the delay will simply be added on top of the next determined elapsing time, unless modified with FixedRandomDelay=,
	// see below.
	//
	// This setting is useful to stretch dispatching of similarly configured timer events over a certain time interval, to prevent
	// them from firing all at the same time, possibly resulting in resource congestion.
	//
	// Note the relation to AccuracySec= above: the latter allows the service manager to coalesce timer events within a specified
	// time range in order to minimize wakeups, while this setting does the opposite: it stretches timer events over an interval,
	// to make it unlikely that they fire simultaneously. If RandomizedDelaySec= and AccuracySec= are used in conjunction,
	// first the randomized delay is added, and then the result is possibly further shifted to coalesce it with other timer events
	// happening on the system. As mentioned above AccuracySec= defaults to 1 minute and RandomizedDelaySec= to 0, thus encouraging
	// coalescing of timer events. In order to optimally stretch timer events over a certain range of time, set AccuracySec=1us
	// and RandomizedDelaySec= to some higher value.
	RandomizedDelaySec systemdconf.Value

	// Takes a boolean argument. When enabled, the randomized offset specified by RandomizedDelaySec= is reused for all firings
	// of the same timer. For a given timer unit, the offset depends on the machine ID, user identifier and timer name, which means
	// that it is stable between restarts of the manager. This effectively creates a fixed offset for an individual timer, reducing
	// the jitter in firings of this timer, while still avoiding firing at the same time as other similarly configured timers.
	//
	// This setting has no effect if RandomizedDelaySec= is set to 0. Defaults to false.
	FixedRandomDelay systemdconf.Value

	// These options take boolean arguments. When true, the service unit will be triggered when the system clock (CLOCK_REALTIME)
	// jumps relative to the monotonic clock (CLOCK_MONOTONIC), or when the local system timezone is modified. These options
	// can be used alone or in combination with other timer expressions (see above) within the same timer unit. These options default
	// to false.
	OnClockChange systemdconf.Value

	// These options take boolean arguments. When true, the service unit will be triggered when the system clock (CLOCK_REALTIME)
	// jumps relative to the monotonic clock (CLOCK_MONOTONIC), or when the local system timezone is modified. These options
	// can be used alone or in combination with other timer expressions (see above) within the same timer unit. These options default
	// to false.
	OnTimezoneChange systemdconf.Value

	// The unit to activate when this timer elapses. The argument is a unit name, whose suffix is not ".timer". If not specified,
	// this value defaults to a service that has the same name as the timer unit, except for the suffix. (See above.) It is recommended
	// that the unit name that is activated and the unit name of the timer unit are named identically, except for the suffix.
	Unit systemdconf.Value

	// Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated,
	// the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was
	// inactive. Such triggering is nonetheless subject to the delay imposed by RandomizedDelaySec=. This is useful to catch
	// up on missed runs of the service when the system was powered down. Note that this setting only has an effect on timers configured
	// with OnCalendar=. Defaults to false.
	//
	// Use systemctl clean --what=state … on the timer unit to remove the timestamp file maintained by this option from disk. In
	// particular, use this command before uninstalling a timer unit. See systemctl for details.
	Persistent systemdconf.Value

	// Takes a boolean argument. If true, an elapsing timer will cause the system to resume from suspend, should it be suspended
	// and if the system supports this. Note that this option will only make sure the system resumes on the appropriate times, it
	// will not take care of suspending it again after any work that is to be done is finished. Defaults to false.
	//
	// Note that this functionality requires privileges and is thus generally only available in the system service manager.
	//
	// Note that behaviour of monotonic clock timers (as configured with OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=,
	// OnUnitInactiveSec=, see above) is altered depending on this option. If false, a monotonic clock is used that is paused
	// during system suspend (CLOCK_MONOTONIC), if true a different monotonic clock is used that continues advancing during
	// system suspend (CLOCK_BOOTTIME), see clock_getres for details.
	WakeSystem systemdconf.Value

	// Takes a boolean argument. If true, a timer will stay loaded, and its state remains queryable even after it elapsed and the
	// associated unit (as configured with Unit=, see above) deactivated again. If false, an elapsed timer unit that cannot elapse
	// anymore is unloaded once its associated unit deactivated again. Turning this off is particularly useful for transient
	// timer units. Note that this setting has an effect when repeatedly starting a timer unit: if RemainAfterElapse= is on, starting
	// the timer a second time has no effect. However, if RemainAfterElapse= is off and the timer unit was already unloaded, it
	// can be started again, and thus the service can be triggered multiple times. Defaults to true.
	RemainAfterElapse systemdconf.Value
}

TimerSection represents information about the timer it defines (see https://www.freedesktop.org/software/systemd/man/systemd.timer.html#Options for details)

type UnitSection 

type UnitSection struct {
	systemdconf.Section

	// 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 continuous verb. Bad examples include "exiting the container" or "updating the database once per day.".
	Description systemdconf.Value

	// 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.
	// 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.
	Documentation systemdconf.Value

	// Configures (weak) requirement dependencies on other units. This option may be specified more than once or multiple space-separated
	// units may be specified in one option in which case dependencies for all listed names will be created. Dependencies of this
	// type may also be configured outside of the unit configuration file by adding a symlink to a .wants/ directory accompanying
	// the unit file. For details, see above.
	//
	// 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, and this unit will still be started.
	// This is the recommended way to hook the start-up of one unit to the start-up of another unit.
	//
	// 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 unit foo.service pulls in unit bar.service as configured with Wants=
	// 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.
	Wants systemdconf.Value

	// Similar to Wants=, but declares a stronger requirement dependency. Dependencies of this type may also be configured by
	// adding a symlink to a .requires/ directory accompanying the unit file.
	//
	// If this unit gets activated, the units listed 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.
	//
	// 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).
	Requires systemdconf.Value

	// 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.
	Requisite systemdconf.Value

	// 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.
	BindsTo systemdconf.Value

	// 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.
	PartOf systemdconf.Value

	// 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 does not imply an ordering dependency, similarly to the Wants= and Requires= dependencies described
	// above. This means that to ensure that the conflicting unit is stopped before the other unit is started, an After= or Before=
	// dependency must be declared. It doesn't matter which of the two ordering dependencies is used, because stop jobs are always
	// ordered before start jobs, see the discussion in Before=/After= below.
	//
	// If unit A that conflicts with 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.
	Conflicts systemdconf.Value

	// These two settings expect a space-separated list of unit names. They may be specified more than once, in which case dependencies
	// for all listed names are created.
	//
	// Those two settings configure ordering dependencies between units. If unit foo.service contains the setting Before=bar.service
	// and both units are being started, bar.service's start-up is delayed until foo.service has finished starting up. After=
	// is the inverse of Before=, i.e. while Before= ensures that the configured unit is started before the listed unit begins
	// starting up, After= ensures the opposite, that the listed unit is fully started up before the configured unit is started.
	//
	// 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. Note that this does includes ExecStartPost=
	// (or ExecStopPost= for the shutdown case).
	//
	// Note that those settings are independent of and orthogonal to the requirement dependencies as configured by Requires=,
	// Wants=, Requisite=, or BindsTo=. It is a common pattern to include a unit name in both the After= and Wants= options, in which
	// case the unit listed will be started before the unit that is configured with these options.
	//
	// Note that Before= dependencies on device units have no effect and are not supported. Devices generally become available
	// as a result of an external hotplug event, and systemd creates the corresponding device unit without delay.
	Before systemdconf.Value

	// These two settings expect a space-separated list of unit names. They may be specified more than once, in which case dependencies
	// for all listed names are created.
	//
	// Those two settings configure ordering dependencies between units. If unit foo.service contains the setting Before=bar.service
	// and both units are being started, bar.service's start-up is delayed until foo.service has finished starting up. After=
	// is the inverse of Before=, i.e. while Before= ensures that the configured unit is started before the listed unit begins
	// starting up, After= ensures the opposite, that the listed unit is fully started up before the configured unit is started.
	//
	// 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. Note that this does includes ExecStartPost=
	// (or ExecStopPost= for the shutdown case).
	//
	// Note that those settings are independent of and orthogonal to the requirement dependencies as configured by Requires=,
	// Wants=, Requisite=, or BindsTo=. It is a common pattern to include a unit name in both the After= and Wants= options, in which
	// case the unit listed will be started before the unit that is configured with these options.
	//
	// Note that Before= dependencies on device units have no effect and are not supported. Devices generally become available
	// as a result of an external hotplug event, and systemd creates the corresponding device unit without delay.
	After systemdconf.Value

	// A space-separated list of one or more units that are activated when this unit enters the "failed" state. A service unit using
	// Restart= enters the failed state only after the start limits are reached.
	OnFailure systemdconf.Value

	// A space-separated list of one or more units where reload requests on this unit will be propagated to, or reload requests
	// on the other unit will be propagated to this unit, respectively. Issuing a reload request on a unit will automatically also
	// enqueue a reload request on all units that the reload request shall be propagated to via these two settings.
	PropagatesReloadTo systemdconf.Value

	// A space-separated list of one or more units where reload requests on this unit will be propagated to, or reload requests
	// on the other unit will be propagated to this unit, respectively. Issuing a reload request on a unit will automatically also
	// enqueue a reload request on all units that the reload request shall be propagated to via these two settings.
	ReloadPropagatedFrom systemdconf.Value

	// For units that start processes (such as service units), lists one or more other units whose network and/or temporary file
	// namespace to join. This only applies to unit types which support the PrivateNetwork=, NetworkNamespacePath= and PrivateTmp=
	// directives (see systemd.exec for details). If a unit that has this setting set is started, its processes will see the same
	// /tmp/, /var/tmp/ and network namespace as one listed unit that is started. If multiple listed units are already started,
	// it is not defined which namespace is joined. Note that this setting only has an effect if PrivateNetwork=/NetworkNamespacePath=
	// and/or PrivateTmp= is enabled for both the unit that joins the namespace and the unit whose namespace is joined.
	JoinsNamespaceOf systemdconf.Value

	// Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all
	// mount units required to access the specified path.
	//
	// Mount points marked with noauto are not mounted automatically through local-fs.target, but are still honored for the
	// purposes of this option, i.e. they will be pulled in by this unit.
	RequiresMountsFor systemdconf.Value

	// Takes a value of "fail", "replace", "replace-irreversibly", "isolate", "flush", "ignore-dependencies" or "ignore-requirements".
	// Defaults to "replace". Specifies how the units listed in OnFailure= will be enqueued. See systemctl's --job-mode= option
	// for details on the possible values. If this is set to "isolate", only a single unit may be listed in OnFailure=.
	OnFailureJobMode systemdconf.Value

	// Takes a boolean argument. If true, this unit will not be stopped when isolating another unit. Defaults to false for service,
	// target, socket, timer, and path units, and true for slice, scope, device, swap, mount, and automount units.
	IgnoreOnIsolate systemdconf.Value

	// Takes a boolean argument. If true, this unit will be stopped when it is no longer used. Note that, in order to minimize the
	// work to be executed, systemd will not stop units by default unless they are conflicting with other units, or the user explicitly
	// requested their shut down. If this option is set, a unit will be automatically cleaned up if no other active unit requires
	// it. Defaults to false.
	StopWhenUnneeded systemdconf.Value

	// Takes a boolean argument. If true, this unit can only be activated or deactivated indirectly. In this case, explicit start-up
	// or termination requested by the user is denied, however if it is started or stopped as a dependency of another unit, start-up
	// or termination will succeed. This is mostly a safety feature to ensure that the user does not accidentally activate units
	// that are not intended to be activated explicitly, and not accidentally deactivate units that are not intended to be deactivated.
	// These options default to false.
	RefuseManualStart systemdconf.Value

	// Takes a boolean argument. If true, this unit can only be activated or deactivated indirectly. In this case, explicit start-up
	// or termination requested by the user is denied, however if it is started or stopped as a dependency of another unit, start-up
	// or termination will succeed. This is mostly a safety feature to ensure that the user does not accidentally activate units
	// that are not intended to be activated explicitly, and not accidentally deactivate units that are not intended to be deactivated.
	// These options default to false.
	RefuseManualStop systemdconf.Value

	// Takes a boolean argument. If true, this unit may be used with the systemctl isolate command. Otherwise, this will be refused.
	// It probably is a good idea to leave this disabled except for target units that shall be used similar to runlevels in SysV init
	// systems, just as a precaution to avoid unusable system states. This option defaults to false.
	AllowIsolate systemdconf.Value

	// Takes a boolean argument. If yes, (the default), a few default dependencies will implicitly be created for the unit. The
	// actual dependencies created depend on the unit type. For example, for service units, these dependencies ensure that the
	// service is started only after basic system initialization is completed and is properly terminated on system shutdown.
	// See the respective man pages for details. Generally, only services involved with early boot or late shutdown should set
	// this option to no. It is highly recommended to leave this option enabled for the majority of common units. If set to no, this
	// option does not disable all implicit dependencies, just non-essential ones.
	DefaultDependencies systemdconf.Value

	// Tweaks the "garbage collection" algorithm for this unit. Takes one of inactive or inactive-or-failed. If set to inactive
	// the unit will be unloaded if it is in the inactive state and is not referenced by clients, jobs or other units — however it is
	// not unloaded if it is in the failed state. In failed mode, failed units are not unloaded until the user invoked systemctl
	// reset-failed on them to reset the failed state, or an equivalent command. This behaviour is altered if this option is set
	// to inactive-or-failed: in this case the unit is unloaded even if the unit is in a failed state, and thus an explicitly resetting
	// of the failed state is not necessary. Note that if this mode is used unit results (such as exit codes, exit signals, consumed
	// resources, …) are flushed out immediately after the unit completed, except for what is stored in the logging subsystem.
	// Defaults to inactive.
	CollectMode systemdconf.Value

	// Configure the action to take when the unit stops and enters a failed state or inactive state. Takes one of none, reboot, reboot-force,
	// reboot-immediate, poweroff, poweroff-force, poweroff-immediate, exit, and exit-force. In system mode, all options
	// are allowed. In user mode, only none, exit, and exit-force are allowed. Both options default to none.
	//
	// If none is set, no action will be triggered. reboot causes a reboot following the normal shutdown procedure (i.e. equivalent
	// to systemctl reboot). reboot-force causes a forced reboot which will terminate all processes forcibly but should cause
	// no dirty file systems on reboot (i.e. equivalent to systemctl reboot -f) and reboot-immediate causes immediate execution
	// of the reboot system call, which might result in data loss (i.e. equivalent to systemctl reboot -ff). Similarly, poweroff,
	// poweroff-force, poweroff-immediate have the effect of powering down the system with similar semantics. exit causes
	// the manager to exit following the normal shutdown procedure, and exit-force causes it terminate without shutting down
	// services. When exit or exit-force is used by default the exit status of the main process of the unit (if this applies) is returned
	// from the service manager. However, this may be overridden with FailureActionExitStatus=/SuccessActionExitStatus=,
	// see below.
	FailureAction systemdconf.Value

	// Configure the action to take when the unit stops and enters a failed state or inactive state. Takes one of none, reboot, reboot-force,
	// reboot-immediate, poweroff, poweroff-force, poweroff-immediate, exit, and exit-force. In system mode, all options
	// are allowed. In user mode, only none, exit, and exit-force are allowed. Both options default to none.
	//
	// If none is set, no action will be triggered. reboot causes a reboot following the normal shutdown procedure (i.e. equivalent
	// to systemctl reboot). reboot-force causes a forced reboot which will terminate all processes forcibly but should cause
	// no dirty file systems on reboot (i.e. equivalent to systemctl reboot -f) and reboot-immediate causes immediate execution
	// of the reboot system call, which might result in data loss (i.e. equivalent to systemctl reboot -ff). Similarly, poweroff,
	// poweroff-force, poweroff-immediate have the effect of powering down the system with similar semantics. exit causes
	// the manager to exit following the normal shutdown procedure, and exit-force causes it terminate without shutting down
	// services. When exit or exit-force is used by default the exit status of the main process of the unit (if this applies) is returned
	// from the service manager. However, this may be overridden with FailureActionExitStatus=/SuccessActionExitStatus=,
	// see below.
	SuccessAction systemdconf.Value

	// Controls the exit status to propagate back to an invoking container manager (in case of a system service) or service manager
	// (in case of a user manager) when the FailureAction=/SuccessAction= are set to exit or exit-force and the action is triggered.
	// By default the exit status of the main process of the triggering unit (if this applies) is propagated. Takes a value in the
	// range 0…255 or the empty string to request default behaviour.
	FailureActionExitStatus systemdconf.Value

	// Controls the exit status to propagate back to an invoking container manager (in case of a system service) or service manager
	// (in case of a user manager) when the FailureAction=/SuccessAction= are set to exit or exit-force and the action is triggered.
	// By default the exit status of the main process of the triggering unit (if this applies) is propagated. Takes a value in the
	// range 0…255 or the empty string to request default behaviour.
	SuccessActionExitStatus systemdconf.Value

	// When a job for this unit is queued, a timeout JobTimeoutSec= may be configured. Similarly, JobRunningTimeoutSec= starts
	// counting when the queued job is actually started. If either time limit is reached, the job will be cancelled, the unit however
	// will not change state or even enter the "failed" mode. This value defaults to "infinity" (job timeouts disabled), except
	// for device units (JobRunningTimeoutSec= defaults to DefaultTimeoutStartSec=). NB: this timeout is independent from
	// any unit-specific timeout (for example, the timeout set with TimeoutStartSec= in service units) as the job timeout has
	// no effect on the unit itself, only on the job that might be pending for it. Or in other words: unit-specific timeouts are useful
	// to abort unit state changes, and revert them. The job timeout set with this option however is useful to abort only the job
	// waiting for the unit state to change.
	JobTimeoutSec systemdconf.Value

	// When a job for this unit is queued, a timeout JobTimeoutSec= may be configured. Similarly, JobRunningTimeoutSec= starts
	// counting when the queued job is actually started. If either time limit is reached, the job will be cancelled, the unit however
	// will not change state or even enter the "failed" mode. This value defaults to "infinity" (job timeouts disabled), except
	// for device units (JobRunningTimeoutSec= defaults to DefaultTimeoutStartSec=). NB: this timeout is independent from
	// any unit-specific timeout (for example, the timeout set with TimeoutStartSec= in service units) as the job timeout has
	// no effect on the unit itself, only on the job that might be pending for it. Or in other words: unit-specific timeouts are useful
	// to abort unit state changes, and revert them. The job timeout set with this option however is useful to abort only the job
	// waiting for the unit state to change.
	JobRunningTimeoutSec systemdconf.Value

	// JobTimeoutAction= optionally configures an additional action to take when the timeout is hit, see description of JobTimeoutSec=
	// and JobRunningTimeoutSec= above. It takes the same values as StartLimitAction=. Defaults to none. JobTimeoutRebootArgument=
	// configures an optional reboot string to pass to the reboot system call.
	JobTimeoutAction systemdconf.Value

	// JobTimeoutAction= optionally configures an additional action to take when the timeout is hit, see description of JobTimeoutSec=
	// and JobRunningTimeoutSec= above. It takes the same values as StartLimitAction=. Defaults to none. JobTimeoutRebootArgument=
	// configures an optional reboot string to pass to the reboot system call.
	JobTimeoutRebootArgument systemdconf.Value

	// 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); 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.
	//
	// When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters are flushed out too. This
	// means that configuring start rate limiting for a unit that is not referenced continuously has no effect.
	StartLimitIntervalSec systemdconf.Value

	// 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); 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.
	//
	// When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters are flushed out too. This
	// means that configuring start rate limiting for a unit that is not referenced continuously has no effect.
	StartLimitBurst systemdconf.Value

	// Configure an additional action to take if the rate limit configured with StartLimitIntervalSec= and StartLimitBurst=
	// is hit. Takes the same values as the FailureAction=/SuccessAction= settings. If none is set, hitting the rate limit will
	// trigger no action except that the start will not be permitted. Defaults to none.
	StartLimitAction systemdconf.Value

	// Configure the optional argument for the reboot system call if StartLimitAction= or FailureAction= is a reboot action.
	// This works just like the optional argument to systemctl reboot command.
	RebootArgument systemdconf.Value

	// A path to a configuration file this unit has been generated from. This is primarily useful for implementation of generator
	// tools that convert configuration from an external configuration file format into native unit files. This functionality
	// should not be used in normal units.
	SourcePath systemdconf.Value

	// Check whether the system is running on a specific architecture. Takes one of "x86", "x86-64", "ppc", "ppc-le", "ppc64",
	// "ppc64-le", "ia64", "parisc", "parisc64", "s390", "s390x", "sparc", "sparc64", "mips", "mips-le", "mips64", "mips64-le",
	// "alpha", "arm", "arm-be", "arm64", "arm64-be", "sh", "sh64", "m68k", "tilegx", "cris", "arc", "arc-be", or "native".
	//
	// The architecture is determined from the information returned by uname and is thus subject to personality. Note that a Personality=
	// setting in the same unit file has no effect on this condition. A special architecture name "native" is mapped to the architecture
	// the system manager itself is compiled for. The test may be negated by prepending an exclamation mark.
	ConditionArchitecture systemdconf.Value

	// Check whether the system is executed in a virtualized environment and optionally test whether it is a specific implementation.
	// Takes either boolean value to check if being executed in any virtualized environment, or one of "vm" and "container" to
	// test against a generic type of virtualization solution, or one of "qemu", "kvm", "zvm", "vmware", "microsoft", "oracle",
	// "powervm", "xen", "bochs", "uml", "bhyve", "qnx", "openvz", "lxc", "lxc-libvirt", "systemd-nspawn", "docker", "podman",
	// "rkt", "wsl", "proot", "pouch", "acrn" to test against a specific implementation, or "private-users" to check whether
	// we are running in a user namespace. See systemd-detect-virt for a full list of known virtualization technologies and their
	// identifiers. If multiple virtualization technologies are nested, only the innermost is considered. The test may be negated
	// by prepending an exclamation mark.
	ConditionVirtualization systemdconf.Value

	// ConditionHost= may be used to match against the hostname or machine ID of the host. This either takes a hostname string (optionally
	// with shell style globs) which is tested against the locally set hostname as returned by gethostname, or a machine ID formatted
	// as string (see machine-id). The test may be negated by prepending an exclamation mark.
	ConditionHost systemdconf.Value

	// ConditionKernelCommandLine= may be used to check whether a specific kernel command line option is set (or if prefixed
	// with the exclamation mark — unset). The argument must either be a single word, or an assignment (i.e. two words, separated
	// by "="). In the former case the kernel command line is searched for the word appearing as is, or as left hand side of an assignment.
	// In the latter case, the exact assignment is looked for with right and left hand side matching. This operates on the kernel
	// command line communicated to userspace via /proc/cmdline, except when the service manager is invoked as payload of a container
	// manager, in which case the command line of PID 1 is used instead (i.e. /proc/1/cmdline).
	ConditionKernelCommandLine systemdconf.Value

	// ConditionKernelVersion= may be used to check whether the kernel version (as reported by uname -r) matches a certain expression
	// (or if prefixed with the exclamation mark does not match it). The argument must be a list of (potentially quoted) expressions.
	// For each of the expressions, if it starts with one of "<", "<=", "=", "!=", ">=", ">" a relative version comparison is done,
	// otherwise the specified string is matched with shell-style globs.
	//
	// Note that using the kernel version string is an unreliable way to determine which features are supported by a kernel, because
	// of the widespread practice of backporting drivers, features, and fixes from newer upstream kernels into older versions
	// provided by distributions. Hence, this check is inherently unportable and should not be used for units which may be used
	// on different distributions.
	ConditionKernelVersion systemdconf.Value

	// ConditionEnvironment= may be used to check whether a specific environment variable is set (or if prefixed with the exclamation
	// mark — unset) in the service manager's environment block. The argument may be a single word, to check if the variable with
	// this name is defined in the environment block, or an assignment ("name=value"), to check if the variable with this exact
	// value is defined. Note that the environment block of the service manager itself is checked, i.e. not any variables defined
	// with Environment= or EnvironmentFile=, as described above. This is particularly useful when the service manager runs
	// inside a containerized environment or as per-user service manager, in order to check for variables passed in by the enclosing
	// container manager or PAM.
	ConditionEnvironment systemdconf.Value

	// ConditionSecurity= may be used to check whether the given security technology is enabled on the system. Currently, the
	// recognized values are "selinux", "apparmor", "tomoyo", "ima", "smack", "audit", "uefi-secureboot" and "tpm2". The
	// test may be negated by prepending an exclamation mark.
	ConditionSecurity systemdconf.Value

	// Check whether the given capability exists in the capability bounding set of the service manager (i.e. this does not check
	// whether capability is actually available in the permitted or effective sets, see capabilities for details). Pass a capability
	// name such as "CAP_MKNOD", possibly prefixed with an exclamation mark to negate the check.
	ConditionCapability systemdconf.Value

	// Check whether the system has AC power, or is exclusively battery powered at the time of activation of the unit. This takes
	// a boolean argument. If set to "true", the condition will hold only if at least one AC connector of the system is connected
	// to a power source, or if no AC connectors are known. Conversely, if set to "false", the condition will hold only if there is
	// at least one AC connector known and all AC connectors are disconnected from a power source.
	ConditionACPower systemdconf.Value

	// Takes one of /var/ or /etc/ as argument, possibly prefixed with a "!" (to invert the condition). This condition may be used
	// to conditionalize units on whether the specified directory requires an update because /usr/'s modification time is newer
	// than the stamp file .updated in the specified directory. This is useful to implement offline updates of the vendor operating
	// system resources in /usr/ that require updating of /etc/ or /var/ on the next following boot. Units making use of this condition
	// should order themselves before systemd-update-done.service, to make sure they run before the stamp file's modification
	// time gets reset indicating a completed update.
	//
	// If the systemd.condition-needs-update= option is specified on the kernel command line (taking a boolean), it will override
	// the result of this condition check, taking precedence over any file modification time checks. If it is used systemd-update-done.service
	// will not have immediate effect on any following ConditionNeedsUpdate= checks, until the system is rebooted where the
	// kernel command line option is not specified anymore.
	ConditionNeedsUpdate systemdconf.Value

	// Takes a boolean argument. This condition may be used to conditionalize units on whether the system is booting up for the
	// first time. This roughly means that /etc/ is unpopulated (for details, see "First Boot Semantics" in machine-id). This
	// may be used to populate /etc/ on the first boot after factory reset, or when a new system instance boots up for the first time.
	//
	// For robustness, units with ConditionFirstBoot=yes should order themselves before first-boot-complete.target and
	// pull in this passive target with Wants=. This ensures that in a case of an aborted first boot, these units will be re-run during
	// the next system startup.
	//
	// If the systemd.condition-first-boot= option is specified on the kernel command line (taking a boolean), it will override
	// the result of this condition check, taking precedence over /etc/machine-id existence checks.
	ConditionFirstBoot systemdconf.Value

	// Check for the exists of a file. If the specified absolute path name does not exist, the condition will fail. If the absolute
	// path name passed to ConditionPathExists= is prefixed with an exclamation mark ("!"), the test is negated, and the unit
	// is only started if the path does not exist.
	ConditionPathExists systemdconf.Value

	// ConditionPathExistsGlob= is similar to ConditionPathExists=, but checks for the existence of at least one file or directory
	// matching the specified globbing pattern.
	ConditionPathExistsGlob systemdconf.Value

	// ConditionPathIsDirectory= is similar to ConditionPathExists= but verifies that a certain path exists and is a directory.
	ConditionPathIsDirectory systemdconf.Value

	// ConditionPathIsSymbolicLink= is similar to ConditionPathExists= but verifies that a certain path exists and is a symbolic
	// link.
	ConditionPathIsSymbolicLink systemdconf.Value

	// ConditionPathIsMountPoint= is similar to ConditionPathExists= but verifies that a certain path exists and is a mount
	// point.
	ConditionPathIsMountPoint systemdconf.Value

	// ConditionPathIsReadWrite= is similar to ConditionPathExists= but verifies that the underlying file system is readable
	// and writable (i.e. not mounted read-only).
	ConditionPathIsReadWrite systemdconf.Value

	// ConditionPathIsEncrypted= is similar to ConditionPathExists= but verifies that the underlying file system's backing
	// block device is encrypted using dm-crypt/LUKS. Note that this check does not cover ext4 per-directory encryption, and
	// only detects block level encryption. Moreover, if the specified path resides on a file system on top of a loopback block
	// device, only encryption above the loopback device is detected. It is not detected whether the file system backing the loopback
	// block device is encrypted.
	ConditionPathIsEncrypted systemdconf.Value

	// ConditionDirectoryNotEmpty= is similar to ConditionPathExists= but verifies that a certain path exists and is a non-empty
	// directory.
	ConditionDirectoryNotEmpty systemdconf.Value

	// ConditionFileNotEmpty= is similar to ConditionPathExists= but verifies that a certain path exists and refers to a regular
	// file with a non-zero size.
	ConditionFileNotEmpty systemdconf.Value

	// ConditionFileIsExecutable= is similar to ConditionPathExists= but verifies that a certain path exists, is a regular
	// file, and marked executable.
	ConditionFileIsExecutable systemdconf.Value

	// ConditionUser= takes a numeric "UID", a UNIX user name, or the special value "@system". This condition may be used to check
	// whether the service manager is running as the given user. The special value "@system" can be used to check if the user id is
	// within the system user range. This option is not useful for system services, as the system manager exclusively runs as the
	// root user, and thus the test result is constant.
	ConditionUser systemdconf.Value

	// ConditionGroup= is similar to ConditionUser= but verifies that the service manager's real or effective group, or any
	// of its auxiliary groups, match the specified group or GID. This setting does not support the special value "@system".
	ConditionGroup systemdconf.Value

	// Verify that the given cgroup controller (eg. "cpu") is available for use on the system. For example, a particular controller
	// may not be available if it was disabled on the kernel command line with cgroup_disable=controller. Multiple controllers
	// may be passed with a space separating them; in this case the condition will only pass if all listed controllers are available
	// for use. Controllers unknown to systemd are ignored. Valid controllers are "cpu", "cpuacct", "io", "blkio", "memory",
	// "devices", and "pids".
	ConditionControlGroupController systemdconf.Value

	// Verify that the specified amount of system memory is available to the current system. Takes a memory size in bytes as argument,
	// optionally prefixed with a comparison operator "<", "<=", "=", "!=", ">=", ">". On bare-metal systems compares the amount
	// of physical memory in the system with the specified size, adhering to the specified comparison operator. In containers
	// compares the amount of memory assigned to the container instead.
	ConditionMemory systemdconf.Value

	// Verify that the specified number of CPUs is available to the current system. Takes a number of CPUs as argument, optionally
	// prefixed with a comparison operator "<", "<=", "=", "!=", ">=", ">". Compares the number of CPUs in the CPU affinity mask
	// configured of the service manager itself with the specified number, adhering to the specified comparison operator. On
	// physical systems the number of CPUs in the affinity mask of the service manager usually matches the number of physical CPUs,
	// but in special and virtual environments might differ. In particular, in containers the affinity mask usually matches
	// the number of CPUs assigned to the container and not the physically available ones.
	ConditionCPUs systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertArchitecture systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertVirtualization systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertHost systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertKernelCommandLine systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertKernelVersion systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertEnvironment systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertSecurity systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertCapability systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertACPower systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertNeedsUpdate systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertFirstBoot systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertPathExists systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertPathExistsGlob systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertPathIsDirectory systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertPathIsSymbolicLink systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertPathIsMountPoint systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertPathIsReadWrite systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertPathIsEncrypted systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertDirectoryNotEmpty systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertFileNotEmpty systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertFileIsExecutable systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertUser systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertGroup systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertControlGroupController systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertMemory systemdconf.Value

	// Similar to the ConditionArchitecture=, ConditionVirtualization=, …, condition settings described above, these settings
	// add assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting that
	// is not met results in failure of the start job (which means this is logged loudly). Note that hitting a configured assertion
	// does not cause the unit to enter the "failed" state (or in fact result in any state change of the unit), it affects only the
	// job queued for it. Use assertion expressions for units that cannot operate when specific requirements are not met, and
	// when this is something the administrator or user should look into.
	AssertCPUs systemdconf.Value
}

UnitSection represents generic information about the unit that is not dependent on the type of unit (see https://www.freedesktop.org/software/systemd/man/systemd.unit.html#%5BUnit%5D%20Section%20Options for details)

Source Files

View all Source files

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL
go.dev uses cookies from Google to deliver and enhance the quality of its services and to analyze traffic. Learn more.