File Coverage

blib/lib/Config/Model/models/Systemd/Common/Exec.pl
Criterion Covered Total %
statement 18 18 100.0
branch n/a
condition n/a
subroutine 6 6 100.0
pod n/a
total 24 24 100.0


line stmt bran cond sub pod time code
1             #
2             # This file is part of Config-Model-Systemd
3             #
4             # This software is Copyright (c) 2008-2022 by Dominique Dumont.
5             #
6             # This is free software, licensed under:
7             #
8             # The GNU Lesser General Public License, Version 2.1, February 1999
9             #
10 4     4   16563 use strict;
  4     1   19  
  4     1   91  
  1         2515  
  1         2  
  1         58  
  1         2606  
  1         2  
  1         17  
11 4     4   17 use warnings;
  4     1   8  
  4     1   14056  
  1         6  
  1         1  
  1         3308  
  1         6  
  1         2  
  1         3890  
12              
13             return [
14             {
15             'accept' => [
16             '.*',
17             {
18             'type' => 'leaf',
19             'value_type' => 'uniline',
20             'warn' => 'Unexpected systemd parameter. Please contact cme author to update systemd model.'
21             }
22             ],
23             'class_description' => 'Unit configuration files for services, sockets, mount points, and swap devices share a subset of
24             configuration options which define the execution environment of spawned processes.
25              
26             This man page lists the configuration options shared by these four unit types. See
27             L<systemd.unit(5)> for the common
28             options of all unit configuration files, and
29             L<systemd.service(5)>,
30             L<systemd.socket(5)>,
31             L<systemd.swap(5)>, and
32             L<systemd.mount(5)> for more
33             information on the specific unit configuration files. The execution specific configuration options are configured
34             in the [Service], [Socket], [Mount], or [Swap] sections, depending on the unit type.
35              
36             In addition, options which control resources through Linux Control Groups (cgroups) are listed in
37             L<systemd.resource-control(5)>.
38             Those options complement options listed here.
39              
40             The following service exit codes are defined by the L<LSB specification|https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html>.
41              
42              
43              
44             The LSB specification suggests that error codes 200 and above are reserved for implementations. Some of them are
45             used by the service manager to indicate problems during process invocation:
46              
47              
48             Finally, the BSD operating systems define a set of exit codes, typically defined on Linux systems too:
49             This configuration class was generated from systemd documentation.
50             by L<parse-man.pl|https://github.com/dod38fr/config-model-systemd/contrib/parse-man.pl>
51             ',
52             'copyright' => [
53             '2010-2016 Lennart Poettering and others',
54             '2016 Dominique Dumont'
55             ],
56             'element' => [
57             'ExecSearchPath',
58             {
59             'cargo' => {
60             'type' => 'leaf',
61             'value_type' => 'uniline'
62             },
63             'description' => 'Takes a colon separated list of absolute paths relative to which the executable
64             used by the C<Exec*=> (e.g. C<ExecStart>,
65             C<ExecStop>, etc.) properties can be found. C<ExecSearchPath>
66             overrides C<$PATH> if C<$PATH> is not supplied by the user through
67             C<Environment>, C<EnvironmentFile> or
68             C<PassEnvironment>. Assigning an empty string removes previous assignments
69             and setting C<ExecSearchPath> to a value multiple times will append
70             to the previous setting.
71             ',
72             'type' => 'list'
73             },
74             'WorkingDirectory',
75             {
76             'description' => 'Takes a directory path relative to the service\'s root directory specified by
77             C<RootDirectory>, or the special value C<~>. Sets the working directory for
78             executed processes. If set to C<~>, the home directory of the user specified in
79             C<User> is used. If not set, defaults to the root directory when systemd is running as a
80             system instance and the respective user\'s home directory if run as user. If the setting is prefixed with the
81             C<-> character, a missing working directory is not considered fatal. If
82             C<RootDirectory>/C<RootImage> is not set, then
83             C<WorkingDirectory> is relative to the root of the system running the service manager. Note
84             that setting this parameter might result in additional dependencies to be added to the unit (see
85             above).',
86             'type' => 'leaf',
87             'value_type' => 'uniline'
88             },
89             'RootDirectory',
90             {
91             'description' => 'Takes a directory path relative to the host\'s root directory (i.e. the root of the system
92             running the service manager). Sets the root directory for executed processes, with the L<chroot(2)> system
93             call. If this is used, it must be ensured that the process binary and all its auxiliary files are available in
94             the chroot() jail. Note that setting this parameter might result in additional
95             dependencies to be added to the unit (see above).
96              
97             The C<MountAPIVFS> and C<PrivateUsers> settings are particularly useful
98             in conjunction with C<RootDirectory>. For details, see below.
99              
100             If C<RootDirectory>/C<RootImage> are used together with
101             C<NotifyAccess> the notification socket is automatically mounted from the host into
102             the root environment, to ensure the notification interface can work correctly.
103              
104             Note that services using C<RootDirectory>/C<RootImage> will
105             not be able to log via the syslog or journal protocols to the host logging infrastructure, unless the
106             relevant sockets are mounted from the host, specifically:',
107             'type' => 'leaf',
108             'value_type' => 'uniline'
109             },
110             'RootImage',
111             {
112             'description' => 'Takes a path to a block device node or regular file as argument. This call is similar
113             to C<RootDirectory> however mounts a file system hierarchy from a block device node
114             or loopback file instead of a directory. The device node or file system image file needs to contain a
115             file system without a partition table, or a file system within an MBR/MS-DOS or GPT partition table
116             with only a single Linux-compatible partition, or a set of file systems within a GPT partition table
117             that follows the L<Discoverable Partitions
118             Specification|https://systemd.io/DISCOVERABLE_PARTITIONS>.
119              
120             When C<DevicePolicy> is set to C<closed> or
121             C<strict>, or set to C<auto> and C<DeviceAllow> is
122             set, then this setting adds C</dev/loop-control> with C<rw> mode,
123             C<block-loop> and C<block-blkext> with C<rwm> mode
124             to C<DeviceAllow>. See
125             L<systemd.resource-control(5)>
126             for the details about C<DevicePolicy> or C<DeviceAllow>. Also, see
127             C<PrivateDevices> below, as it may change the setting of
128             C<DevicePolicy>.
129              
130             Units making use of C<RootImage> automatically gain an
131             C<After> dependency on C<systemd-udevd.service>.',
132             'type' => 'leaf',
133             'value_type' => 'uniline'
134             },
135             'RootImageOptions',
136             {
137             'description' => 'Takes a comma-separated list of mount options that will be used on disk images specified by
138             C<RootImage>. Optionally a partition name can be prefixed, followed by colon, in
139             case the image has multiple partitions, otherwise partition name C<root> is implied.
140             Options for multiple partitions can be specified in a single line with space separators. Assigning an empty
141             string removes previous assignments. Duplicated options are ignored. For a list of valid mount options, please
142             refer to
143             L<mount(8)>.
144              
145             Valid partition names follow the L<Discoverable Partitions Specification|https://systemd.io/DISCOVERABLE_PARTITIONS>:
146             C<root>, C<usr>, C<home>, C<srv>,
147             C<esp>, C<xbootldr>, C<tmp>,
148             C<var>.',
149             'type' => 'leaf',
150             'value_type' => 'uniline'
151             },
152             'RootHash',
153             {
154             'description' => 'Takes a data integrity (dm-verity) root hash specified in hexadecimal, or the path to a file
155             containing a root hash in ASCII hexadecimal format. This option enables data integrity checks using dm-verity,
156             if the used image contains the appropriate integrity data (see above) or if C<RootVerity> is used.
157             The specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64
158             formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but
159             the image file carries the C<user.verity.roothash> extended file attribute (see L<xattr(7)>), then the root
160             hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or
161             is not supported by the underlying file system), but a file with the C<.roothash> suffix is
162             found next to the image file, bearing otherwise the same name (except if the image has the
163             C<.raw> suffix, in which case the root hash file must not have it in its name), the root hash
164             is read from it and automatically used, also as formatted hexadecimal characters.
165              
166             If the disk image contains a separate C</usr/> partition it may also be
167             Verity protected, in which case the root hash may configured via an extended attribute
168             C<user.verity.usrhash> or a C<.usrhash> file adjacent to the disk
169             image. There\'s currently no option to configure the root hash for the C</usr/> file
170             system via the unit file directly.',
171             'type' => 'leaf',
172             'value_type' => 'uniline'
173             },
174             'RootHashSignature',
175             {
176             'description' => 'Takes a PKCS7 signature of the C<RootHash> option as a path to a
177             DER-encoded signature file, or as an ASCII base64 string encoding of a DER-encoded signature prefixed
178             by C<base64:>. The dm-verity volume will only be opened if the signature of the root
179             hash is valid and signed by a public key present in the kernel keyring. If this option is not
180             specified, but a file with the C<.roothash.p7s> suffix is found next to the image
181             file, bearing otherwise the same name (except if the image has the C<.raw> suffix,
182             in which case the signature file must not have it in its name), the signature is read from it and
183             automatically used.
184              
185             If the disk image contains a separate C</usr/> partition it may also be
186             Verity protected, in which case the signature for the root hash may configured via a
187             C<.usrhash.p7s> file adjacent to the disk image. There\'s currently no option to
188             configure the root hash signature for the C</usr/> via the unit file
189             directly.',
190             'type' => 'leaf',
191             'value_type' => 'uniline'
192             },
193             'RootVerity',
194             {
195             'description' => 'Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks
196             using dm-verity, if C<RootImage> is used and a root-hash is passed and if the used image itself
197             does not contains the integrity data. The integrity data must be matched by the root hash. If this option is not
198             specified, but a file with the C<.verity> suffix is found next to the image file, bearing otherwise
199             the same name (except if the image has the C<.raw> suffix, in which case the verity data file must
200             not have it in its name), the verity data is read from it and automatically used.
201              
202             This option is supported only for disk images that contain a single file system, without an
203             enveloping partition table. Images that contain a GPT partition table should instead include both
204             root file system and matching Verity data in the same image, implementing the L<Discoverable Partitions Specification|https://systemd.io/DISCOVERABLE_PARTITIONS>.',
205             'type' => 'leaf',
206             'value_type' => 'uniline'
207             },
208             'MountAPIVFS',
209             {
210             'description' => 'Takes a boolean argument. If on, a private mount namespace for the unit\'s processes is created
211             and the API file systems C</proc/>, C</sys/>, C</dev/> and
212             C</run/> (as an empty C<tmpfs>) are mounted inside of it, unless they are
213             already mounted. Note that this option has no effect unless used in conjunction with
214             C<RootDirectory>/C<RootImage> as these four mounts are
215             generally mounted in the host anyway, and unless the root directory is changed, the private mount namespace
216             will be a 1:1 copy of the host\'s, and include these four mounts. Note that the C</dev/> file
217             system of the host is bind mounted if this option is used without C<PrivateDevices>. To run
218             the service with a private, minimal version of C</dev/>, combine this option with
219             C<PrivateDevices>.
220              
221             In order to allow propagating mounts at runtime in a safe manner, C</run/systemd/propagate>
222             on the host will be used to set up new mounts, and C</run/host/incoming/> in the private namespace
223             will be used as an intermediate step to store them before being moved to the final mount point.',
224             'type' => 'leaf',
225             'value_type' => 'boolean',
226             'write_as' => [
227             'no',
228             'yes'
229             ]
230             },
231             'ProtectProc',
232             {
233             'choice' => [
234             'noaccess',
235             'invisible',
236             'ptraceable',
237             'default'
238             ],
239             'description' => 'Takes one of C<noaccess>, C<invisible>,
240             C<ptraceable> or C<default> (which it defaults to). When set, this
241             controls the C<hidepid=> mount option of the C<procfs> instance for
242             the unit that controls which directories with process metainformation
243             (C</proc/PID>) are visible and accessible: when set to
244             C<noaccess> the ability to access most of other users\' process metadata in
245             C</proc/> is taken away for processes of the service. When set to
246             C<invisible> processes owned by other users are hidden from
247             C</proc/>. If C<ptraceable> all processes that cannot be
248             ptrace()\'ed by a process are hidden to it. If C<default> no
249             restrictions on C</proc/> access or visibility are made. For further details see
250             L<The /proc
251             Filesystem|https://www.kernel.org/doc/html/latest/filesystems/proc.html#mount-options>. It is generally recommended to run most system services with this option set to
252             C<invisible>. This option is implemented via file system namespacing, and thus cannot
253             be used with services that shall be able to install mount points in the host file system
254             hierarchy. Note that the root user is unaffected by this option, so to be effective it has to be used
255             together with C<User> or C<DynamicUser=yes>, and also without the
256             C<CAP_SYS_PTRACE> capability, which also allows a process to bypass this feature. It
257             cannot be used for services that need to access metainformation about other users\' processes. This
258             option implies C<MountAPIVFS>.
259              
260             If the kernel doesn\'t support per-mount point C<hidepid=> mount options this
261             setting remains without effect, and the unit\'s processes will be able to access and see other process
262             as if the option was not used.',
263             'type' => 'leaf',
264             'value_type' => 'enum'
265             },
266             'ProcSubset',
267             {
268             'choice' => [
269             'all',
270             'pid'
271             ],
272             'description' => 'Takes one of C<all> (the default) and C<pid>. If
273             C<pid>, all files and directories not directly associated with process management and
274             introspection are made invisible in the C</proc/> file system configured for the
275             unit\'s processes. This controls the C<subset=> mount option of the
276             C<procfs> instance for the unit. For further details see L<The /proc
277             Filesystem|https://www.kernel.org/doc/html/latest/filesystems/proc.html#mount-options>. Note that Linux exposes various kernel APIs via C</proc/>,
278             which are made unavailable with this setting. Since these APIs are used frequently this option is
279             useful only in a few, specific cases, and is not suitable for most non-trivial programs.
280              
281             Much like C<ProtectProc> above, this is implemented via file system mount
282             namespacing, and hence the same restrictions apply: it is only available to system services, it
283             disables mount propagation to the host mount table, and it implies
284             C<MountAPIVFS>. Also, like C<ProtectProc> this setting is gracefully
285             disabled if the used kernel does not support the C<subset=> mount option of
286             C<procfs>.',
287             'type' => 'leaf',
288             'value_type' => 'enum'
289             },
290             'BindPaths',
291             {
292             'cargo' => {
293             'type' => 'leaf',
294             'value_type' => 'uniline'
295             },
296             'description' => 'Configures unit-specific bind mounts. A bind mount makes a particular file or directory
297             available at an additional place in the unit\'s view of the file system. Any bind mounts created with this
298             option are specific to the unit, and are not visible in the host\'s mount table. This option expects a
299             whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of
300             source path, destination path and option string, where the latter two are optional. If only a source path is
301             specified the source and destination is taken to be the same. The option string may be either
302             C<rbind> or C<norbind> for configuring a recursive or non-recursive bind
303             mount. If the destination path is omitted, the option string must be omitted too.
304             Each bind mount definition may be prefixed with C<->, in which case it will be ignored
305             when its source path does not exist.
306              
307             C<BindPaths> creates regular writable bind mounts (unless the source file system mount
308             is already marked read-only), while C<BindReadOnlyPaths> creates read-only bind mounts. These
309             settings may be used more than once, each usage appends to the unit\'s list of bind mounts. If the empty string
310             is assigned to either of these two options the entire list of bind mounts defined prior to this is reset. Note
311             that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is
312             used.
313              
314             This option is particularly useful when C<RootDirectory>/C<RootImage>
315             is used. In this case the source path refers to a path on the host file system, while the destination path
316             refers to a path below the root directory of the unit.
317              
318             Note that the destination directory must exist or systemd must be able to create it. Thus, it
319             is not possible to use those options for mount points nested underneath paths specified in
320             C<InaccessiblePaths>, or under C</home/> and other protected
321             directories if C<ProtectHome=yes> is
322             specified. C<TemporaryFileSystem> with C<:ro> or
323             C<ProtectHome=tmpfs> should be used instead.',
324             'type' => 'list'
325             },
326             'BindReadOnlyPaths',
327             {
328             'cargo' => {
329             'type' => 'leaf',
330             'value_type' => 'uniline'
331             },
332             'description' => 'Configures unit-specific bind mounts. A bind mount makes a particular file or directory
333             available at an additional place in the unit\'s view of the file system. Any bind mounts created with this
334             option are specific to the unit, and are not visible in the host\'s mount table. This option expects a
335             whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of
336             source path, destination path and option string, where the latter two are optional. If only a source path is
337             specified the source and destination is taken to be the same. The option string may be either
338             C<rbind> or C<norbind> for configuring a recursive or non-recursive bind
339             mount. If the destination path is omitted, the option string must be omitted too.
340             Each bind mount definition may be prefixed with C<->, in which case it will be ignored
341             when its source path does not exist.
342              
343             C<BindPaths> creates regular writable bind mounts (unless the source file system mount
344             is already marked read-only), while C<BindReadOnlyPaths> creates read-only bind mounts. These
345             settings may be used more than once, each usage appends to the unit\'s list of bind mounts. If the empty string
346             is assigned to either of these two options the entire list of bind mounts defined prior to this is reset. Note
347             that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is
348             used.
349              
350             This option is particularly useful when C<RootDirectory>/C<RootImage>
351             is used. In this case the source path refers to a path on the host file system, while the destination path
352             refers to a path below the root directory of the unit.
353              
354             Note that the destination directory must exist or systemd must be able to create it. Thus, it
355             is not possible to use those options for mount points nested underneath paths specified in
356             C<InaccessiblePaths>, or under C</home/> and other protected
357             directories if C<ProtectHome=yes> is
358             specified. C<TemporaryFileSystem> with C<:ro> or
359             C<ProtectHome=tmpfs> should be used instead.',
360             'type' => 'list'
361             },
362             'MountImages',
363             {
364             'cargo' => {
365             'type' => 'leaf',
366             'value_type' => 'uniline'
367             },
368             'description' => 'This setting is similar to C<RootImage> in that it mounts a file
369             system hierarchy from a block device node or loopback file, but the destination directory can be
370             specified as well as mount options. This option expects a whitespace separated list of mount
371             definitions. Each definition consists of a colon-separated tuple of source path and destination
372             definitions, optionally followed by another colon and a list of mount options.
373              
374             Mount options may be defined as a single comma-separated list of options, in which case they
375             will be implicitly applied to the root partition on the image, or a series of colon-separated tuples
376             of partition name and mount options. Valid partition names and mount options are the same as for
377             C<RootImageOptions> setting described above.
378              
379             Each mount definition may be prefixed with C<->, in which case it will be
380             ignored when its source path does not exist. The source argument is a path to a block device node or
381             regular file. If source or destination contain a C<:>, it needs to be escaped as
382             C<\\:>. The device node or file system image file needs to follow the same rules as
383             specified for C<RootImage>. Any mounts created with this option are specific to the
384             unit, and are not visible in the host\'s mount table.
385              
386             These settings may be used more than once, each usage appends to the unit\'s list of mount
387             paths. If the empty string is assigned, the entire list of mount paths defined prior to this is
388             reset.
389              
390             Note that the destination directory must exist or systemd must be able to create it. Thus, it
391             is not possible to use those options for mount points nested underneath paths specified in
392             C<InaccessiblePaths>, or under C</home/> and other protected
393             directories if C<ProtectHome=yes> is specified.
394              
395             When C<DevicePolicy> is set to C<closed> or
396             C<strict>, or set to C<auto> and C<DeviceAllow> is
397             set, then this setting adds C</dev/loop-control> with C<rw> mode,
398             C<block-loop> and C<block-blkext> with C<rwm> mode
399             to C<DeviceAllow>. See
400             L<systemd.resource-control(5)>
401             for the details about C<DevicePolicy> or C<DeviceAllow>. Also, see
402             C<PrivateDevices> below, as it may change the setting of
403             C<DevicePolicy>.',
404             'type' => 'list'
405             },
406             'ExtensionImages',
407             {
408             'cargo' => {
409             'type' => 'leaf',
410             'value_type' => 'uniline'
411             },
412             'description' => 'This setting is similar to C<MountImages> in that it mounts a file
413             system hierarchy from a block device node or loopback file, but instead of providing a destination
414             path, an overlay will be set up. This option expects a whitespace separated list of mount
415             definitions. Each definition consists of a source path, optionally followed by a colon and a list of
416             mount options.
417              
418             A read-only OverlayFS will be set up on top of C</usr/> and
419             C</opt/> hierarchies. The order in which the images are listed will determine the
420             order in which the overlay is laid down: images specified first to last will result in overlayfs
421             layers bottom to top.
422              
423             Mount options may be defined as a single comma-separated list of options, in which case they
424             will be implicitly applied to the root partition on the image, or a series of colon-separated tuples
425             of partition name and mount options. Valid partition names and mount options are the same as for
426             C<RootImageOptions> setting described above.
427              
428             Each mount definition may be prefixed with C<->, in which case it will be
429             ignored when its source path does not exist. The source argument is a path to a block device node or
430             regular file. If the source path contains a C<:>, it needs to be escaped as
431             C<\\:>. The device node or file system image file needs to follow the same rules as
432             specified for C<RootImage>. Any mounts created with this option are specific to the
433             unit, and are not visible in the host\'s mount table.
434              
435             These settings may be used more than once, each usage appends to the unit\'s list of image
436             paths. If the empty string is assigned, the entire list of mount paths defined prior to this is
437             reset.
438              
439             Each image must carry a C</usr/lib/extension-release.d/extension-release.IMAGE>
440             file, with the appropriate metadata which matches C<RootImage>/C<RootDirectory>
441             or the host. See:
442             L<os-release(5)>.
443              
444             When C<DevicePolicy> is set to C<closed> or
445             C<strict>, or set to C<auto> and C<DeviceAllow> is
446             set, then this setting adds C</dev/loop-control> with C<rw> mode,
447             C<block-loop> and C<block-blkext> with C<rwm> mode
448             to C<DeviceAllow>. See
449             L<systemd.resource-control(5)>
450             for the details about C<DevicePolicy> or C<DeviceAllow>. Also, see
451             C<PrivateDevices> below, as it may change the setting of
452             C<DevicePolicy>.',
453             'type' => 'list'
454             },
455             'ExtensionDirectories',
456             {
457             'cargo' => {
458             'type' => 'leaf',
459             'value_type' => 'uniline'
460             },
461             'description' => 'This setting is similar to C<BindReadOnlyPaths> in that it mounts a file
462             system hierarchy from a directory, but instead of providing a destination path, an overlay will be set
463             up. This option expects a whitespace separated list of source directories.
464              
465             A read-only OverlayFS will be set up on top of C</usr/> and
466             C</opt/> hierarchies. The order in which the directories are listed will determine
467             the order in which the overlay is laid down: directories specified first to last will result in overlayfs
468             layers bottom to top.
469              
470             Each directory listed in C<ExtensionDirectories> may be prefixed with C<->,
471             in which case it will be ignored when its source path does not exist. Any mounts created with this option are
472             specific to the unit, and are not visible in the host\'s mount table.
473              
474             These settings may be used more than once, each usage appends to the unit\'s list of directories
475             paths. If the empty string is assigned, the entire list of mount paths defined prior to this is
476             reset.
477              
478             Each directory must contain a C</usr/lib/extension-release.d/extension-release.IMAGE>
479             file, with the appropriate metadata which matches C<RootImage>/C<RootDirectory>
480             or the host. See:
481             L<os-release(5)>.
482              
483             Note that usage from user units requires overlayfs support in unprivileged user namespaces,
484             which was first introduced in kernel v5.11.',
485             'type' => 'list'
486             },
487             'User',
488             {
489             'description' => "Set the UNIX user or group that the processes are executed as, respectively. Takes a single
490             user or group name, or a numeric ID as argument. For system services (services run by the system service
491             manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of
492             systemd --user), the default is C<root>, but C<User> may be
493             used to specify a different user. For user services of any other user, switching user identity is not
494             permitted, hence the only valid setting is the same user the user's service manager is running as. If no group
495             is set, the default group of the user is used. This setting does not affect commands whose command line is
496             prefixed with C<+>.
497              
498             Note that this enforces only weak restrictions on the user/group name syntax, but will generate
499             warnings in many cases where user/group names do not adhere to the following rules: the specified
500             name should consist only of the characters a-z, A-Z, 0-9, C<_> and
501             C<->, except for the first character which must be one of a-z, A-Z and
502             C<_> (i.e. digits and C<-> are not permitted as first character). The
503             user/group name must have at least one character, and at most 31. These restrictions are made in
504             order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux
505             systems. For further details on the names accepted and the names warned about see L<User/Group Name Syntax|https://systemd.io/USER_NAMES>.
506              
507             When used in conjunction with C<DynamicUser> the user/group name specified is
508             dynamically allocated at the time the service is started, and released at the time the service is
509             stopped \x{2014} unless it is already allocated statically (see below). If C<DynamicUser>
510             is not used the specified user and group must have been created statically in the user database no
511             later than the moment the service is started, for example using the
512             L<sysusers.d(5)>
513             facility, which is applied at boot or package install time. If the user does not exist by then
514             program invocation will fail.
515              
516             If the C<User> setting is used the supplementary group list is initialized
517             from the specified user's default group list, as defined in the system's user and group
518             database. Additional groups may be configured through the C<SupplementaryGroups>
519             setting (see below).",
520             'type' => 'leaf',
521             'value_type' => 'uniline'
522             },
523             'Group',
524             {
525             'description' => "Set the UNIX user or group that the processes are executed as, respectively. Takes a single
526             user or group name, or a numeric ID as argument. For system services (services run by the system service
527             manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of
528             systemd --user), the default is C<root>, but C<User> may be
529             used to specify a different user. For user services of any other user, switching user identity is not
530             permitted, hence the only valid setting is the same user the user's service manager is running as. If no group
531             is set, the default group of the user is used. This setting does not affect commands whose command line is
532             prefixed with C<+>.
533              
534             Note that this enforces only weak restrictions on the user/group name syntax, but will generate
535             warnings in many cases where user/group names do not adhere to the following rules: the specified
536             name should consist only of the characters a-z, A-Z, 0-9, C<_> and
537             C<->, except for the first character which must be one of a-z, A-Z and
538             C<_> (i.e. digits and C<-> are not permitted as first character). The
539             user/group name must have at least one character, and at most 31. These restrictions are made in
540             order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux
541             systems. For further details on the names accepted and the names warned about see L<User/Group Name Syntax|https://systemd.io/USER_NAMES>.
542              
543             When used in conjunction with C<DynamicUser> the user/group name specified is
544             dynamically allocated at the time the service is started, and released at the time the service is
545             stopped \x{2014} unless it is already allocated statically (see below). If C<DynamicUser>
546             is not used the specified user and group must have been created statically in the user database no
547             later than the moment the service is started, for example using the
548             L<sysusers.d(5)>
549             facility, which is applied at boot or package install time. If the user does not exist by then
550             program invocation will fail.
551              
552             If the C<User> setting is used the supplementary group list is initialized
553             from the specified user's default group list, as defined in the system's user and group
554             database. Additional groups may be configured through the C<SupplementaryGroups>
555             setting (see below).",
556             'type' => 'leaf',
557             'value_type' => 'uniline'
558             },
559             'DynamicUser',
560             {
561             'description' => "Takes a boolean parameter. If set, a UNIX user and group pair is allocated
562             dynamically when the unit is started, and released as soon as it is stopped. The user and group will
563             not be added to C</etc/passwd> or C</etc/group>, but are managed
564             transiently during runtime. The
565             L<nss-systemd(8)> glibc
566             NSS module provides integration of these dynamic users/groups into the system's user and group
567             databases. The user and group name to use may be configured via C<User> and
568             C<Group> (see above). If these options are not used and dynamic user/group
569             allocation is enabled for a unit, the name of the dynamic user/group is implicitly derived from the
570             unit name. If the unit name without the type suffix qualifies as valid user name it is used directly,
571             otherwise a name incorporating a hash of it is used. If a statically allocated user or group of the
572             configured name already exists, it is used and no dynamic user/group is allocated. Note that if
573             C<User> is specified and the static group with the name exists, then it is required
574             that the static user with the name already exists. Similarly, if C<Group> is
575             specified and the static user with the name exists, then it is required that the static group with
576             the name already exists. Dynamic users/groups are allocated from the UID/GID range 61184\x{2026}65519. It is
577             recommended to avoid this range for regular system or login users. At any point in time each UID/GID
578             from this range is only assigned to zero or one dynamically allocated users/groups in use. However,
579             UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as
580             part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by
581             these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus
582             gain access to these files or directories. If C<DynamicUser> is enabled,
583             C<RemoveIPC> and C<PrivateTmp> are implied (and cannot be turned
584             off). This ensures that the lifetime of IPC objects and temporary files created by the executed
585             processes is bound to the runtime of the service, and hence the lifetime of the dynamic
586             user/group. Since C</tmp/> and C</var/tmp/> are usually the only
587             world-writable directories on a system this ensures that a unit making use of dynamic user/group
588             allocation cannot leave files around after unit termination. Furthermore
589             C<NoNewPrivileges> and C<RestrictSUIDSGID> are implicitly enabled
590             (and cannot be disabled), to ensure that processes invoked cannot take benefit or create SUID/SGID
591             files or directories. Moreover C<ProtectSystem=strict> and
592             C<ProtectHome=read-only> are implied, thus prohibiting the service to write to
593             arbitrary file system locations. In order to allow the service to write to certain directories, they
594             have to be allow-listed using C<ReadWritePaths>, but care must be taken so that
595             UID/GID recycling doesn't create security issues involving files created by the service. Use
596             C<RuntimeDirectory> (see below) in order to assign a writable runtime directory to a
597             service, owned by the dynamic user/group and removed automatically when the unit is terminated. Use
598             C<StateDirectory>, C<CacheDirectory> and
599             C<LogsDirectory> in order to assign a set of writable directories for specific
600             purposes to the service in a way that they are protected from vulnerabilities due to UID reuse (see
601             below). If this option is enabled, care should be taken that the unit's processes do not get access
602             to directories outside of these explicitly configured and managed ones. Specifically, do not use
603             C<BindPaths> and be careful with C<AF_UNIX> file descriptor
604             passing for directory file descriptors, as this would permit processes to create files or directories
605             owned by the dynamic user/group that are not subject to the lifecycle and access guarantees of the
606             service. Defaults to off.",
607             'type' => 'leaf',
608             'value_type' => 'boolean',
609             'write_as' => [
610             'no',
611             'yes'
612             ]
613             },
614             'SupplementaryGroups',
615             {
616             'cargo' => {
617             'type' => 'leaf',
618             'value_type' => 'uniline'
619             },
620             'description' => 'Sets the supplementary Unix groups the processes are executed as. This takes a space-separated
621             list of group names or IDs. This option may be specified more than once, in which case all listed groups are
622             set as supplementary groups. When the empty string is assigned, the list of supplementary groups is reset, and
623             all assignments prior to this one will have no effect. In any way, this option does not override, but extends
624             the list of supplementary groups configured in the system group database for the user. This does not affect
625             commands prefixed with C<+>.',
626             'type' => 'list'
627             },
628             'PAMName',
629             {
630             'description' => 'Sets the PAM service name to set up a session as. If set, the executed process will be
631             registered as a PAM session under the specified service name. This is only useful in conjunction with the
632             C<User> setting, and is otherwise ignored. If not set, no PAM session will be opened for the
633             executed processes. See L<pam(8)> for
634             details.
635              
636             Note that for each unit making use of this option a PAM session handler process will be maintained as
637             part of the unit and stays around as long as the unit is active, to ensure that appropriate actions can be
638             taken when the unit and hence the PAM session terminates. This process is named C<(sd-pam)> and
639             is an immediate child process of the unit\'s main process.
640              
641             Note that when this option is used for a unit it is very likely (depending on PAM configuration) that the
642             main unit process will be migrated to its own session scope unit when it is activated. This process will hence
643             be associated with two units: the unit it was originally started from (and for which
644             C<PAMName> was configured), and the session scope unit. Any child processes of that process
645             will however be associated with the session scope unit only. This has implications when used in combination
646             with C<NotifyAccess>C<all>, as these child processes will not be able to affect
647             changes in the original unit through notification messages. These messages will be considered belonging to the
648             session scope unit and not the original unit. It is hence not recommended to use C<PAMName> in
649             combination with C<NotifyAccess>C<all>.',
650             'type' => 'leaf',
651             'value_type' => 'uniline'
652             },
653             'CapabilityBoundingSet',
654             {
655             'description' => 'Controls which capabilities to include in the capability bounding set for the
656             executed process. See L<capabilities(7)>
657             for details. Takes a whitespace-separated list of capability names,
658             e.g. C<CAP_SYS_ADMIN>, C<CAP_DAC_OVERRIDE>,
659             C<CAP_SYS_PTRACE>. Capabilities listed will be included in the bounding set, all
660             others are removed. If the list of capabilities is prefixed with C<~>, all but the
661             listed capabilities will be included, the effect of the assignment inverted. Note that this option
662             also affects the respective capabilities in the effective, permitted and inheritable capability
663             sets. If this option is not used, the capability bounding set is not modified on process execution,
664             hence no limits on the capabilities of the process are enforced. This option may appear more than
665             once, in which case the bounding sets are merged by C<OR>, or by
666             C<AND> if the lines are prefixed with C<~> (see below). If the
667             empty string is assigned to this option, the bounding set is reset to the empty capability set, and
668             all prior settings have no effect. If set to C<~> (without any further argument),
669             the bounding set is reset to the full set of available capabilities, also undoing any previous
670             settings. This does not affect commands prefixed with C<+>.
671              
672             Use
673             L<systemd-analyze(1)>\'s
674             capability command to retrieve a list of capabilities defined on the local
675             system.
676              
677             Example: if a unit has the following,
678              
679             CapabilityBoundingSet=CAP_A CAP_B
680             CapabilityBoundingSet=CAP_B CAP_C
681              
682             then C<CAP_A>, C<CAP_B>, and
683             C<CAP_C> are set. If the second line is prefixed with
684             C<~>, e.g.,
685              
686             CapabilityBoundingSet=CAP_A CAP_B
687             CapabilityBoundingSet=~CAP_B CAP_C
688              
689             then, only C<CAP_A> is set.',
690             'type' => 'leaf',
691             'value_type' => 'uniline'
692             },
693             'AmbientCapabilities',
694             {
695             'description' => 'Controls which capabilities to include in the ambient capability set for the executed
696             process. Takes a whitespace-separated list of capability names, e.g. C<CAP_SYS_ADMIN>,
697             C<CAP_DAC_OVERRIDE>, C<CAP_SYS_PTRACE>. This option may appear more than
698             once in which case the ambient capability sets are merged (see the above examples in
699             C<CapabilityBoundingSet>). If the list of capabilities is prefixed with C<~>,
700             all but the listed capabilities will be included, the effect of the assignment inverted. If the empty string is
701             assigned to this option, the ambient capability set is reset to the empty capability set, and all prior
702             settings have no effect. If set to C<~> (without any further argument), the ambient capability
703             set is reset to the full set of available capabilities, also undoing any previous settings. Note that adding
704             capabilities to ambient capability set adds them to the process\'s inherited capability set.
705              
706             Ambient capability sets are useful if you want to execute a process as a non-privileged user but still want to
707             give it some capabilities. Note that in this case option C<keep-caps> is automatically added
708             to C<SecureBits> to retain the capabilities over the user
709             change. C<AmbientCapabilities> does not affect commands prefixed with
710             C<+>.',
711             'type' => 'leaf',
712             'value_type' => 'uniline'
713             },
714             'NoNewPrivileges',
715             {
716             'description' => 'Takes a boolean argument. If true, ensures that the service process and all its
717             children can never gain new privileges through execve() (e.g. via setuid or
718             setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that
719             a process and its children can never elevate privileges again. Defaults to false, but certain
720             settings override this and ignore the value of this setting. This is the case when
721             C<DynamicUser>,
722             C<LockPersonality>,
723             C<MemoryDenyWriteExecute>,
724             C<PrivateDevices>,
725             C<ProtectClock>,
726             C<ProtectHostname>,
727             C<ProtectKernelLogs>,
728             C<ProtectKernelModules>,
729             C<ProtectKernelTunables>,
730             C<RestrictAddressFamilies>,
731             C<RestrictNamespaces>,
732             C<RestrictRealtime>,
733             C<RestrictSUIDSGID>,
734             C<SystemCallArchitectures>,
735             C<SystemCallFilter>, or
736             C<SystemCallLog> are specified. Note that even if this setting is overridden
737             by them, systemctl show shows the original value of this setting. In case the
738             service will be run in a new mount namespace anyway and SELinux is disabled, all file systems
739             are mounted with C<MS_NOSUID> flag. Also see
740             L<No New
741             Privileges Flag|https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html>.',
742             'type' => 'leaf',
743             'value_type' => 'boolean',
744             'write_as' => [
745             'no',
746             'yes'
747             ]
748             },
749             'SecureBits',
750             {
751             'description' => 'Controls the secure bits set for the executed process. Takes a space-separated combination of
752             options from the following list: C<keep-caps>, C<keep-caps-locked>,
753             C<no-setuid-fixup>, C<no-setuid-fixup-locked>, C<noroot>, and
754             C<noroot-locked>. This option may appear more than once, in which case the secure bits are
755             ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands
756             prefixed with C<+>. See L<capabilities(7)> for
757             details.',
758             'type' => 'leaf',
759             'value_type' => 'uniline'
760             },
761             'SELinuxContext',
762             {
763             'description' => 'Set the SELinux security context of the executed process. If set, this will override the
764             automated domain transition. However, the policy still needs to authorize the transition. This directive is
765             ignored if SELinux is disabled. If prefixed by C<->, failing to set the SELinux
766             security context will be ignored, but it\'s still possible that the subsequent
767             execve() may fail if the policy doesn\'t allow the transition for the
768             non-overridden context. This does not affect commands prefixed with C<+>. See
769             L<setexeccon(3)>
770             for details.',
771             'type' => 'leaf',
772             'value_type' => 'uniline'
773             },
774             'AppArmorProfile',
775             {
776             'description' => 'Takes a profile name as argument. The process executed by the unit will switch to
777             this profile when started. Profiles must already be loaded in the kernel, or the unit will fail. If
778             prefixed by C<->, all errors will be ignored. This setting has no effect if AppArmor
779             is not enabled. This setting does not affect commands prefixed with C<+>.',
780             'type' => 'leaf',
781             'value_type' => 'uniline'
782             },
783             'SmackProcessLabel',
784             {
785             'description' => 'Takes a C<SMACK64> security label as argument. The process executed by the unit
786             will be started under this label and SMACK will decide whether the process is allowed to run or not, based on
787             it. The process will continue to run under the label specified here unless the executable has its own
788             C<SMACK64EXEC> label, in which case the process will transition to run under that label. When not
789             specified, the label that systemd is running under is used. This directive is ignored if SMACK is
790             disabled.
791              
792             The value may be prefixed by C<->, in which case all errors will be ignored. An empty
793             value may be specified to unset previous assignments. This does not affect commands prefixed with
794             C<+>.',
795             'type' => 'leaf',
796             'value_type' => 'uniline'
797             },
798             'LimitCPU',
799             {
800             'description' => "Set soft and hard limits on various resources for executed processes. See
801             L<setrlimit(2)> for
802             details on the resource limit concept. Resource limits may be specified in two formats: either as
803             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
804             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
805             Use the string C<infinity> to configure no limit on a specific resource. The
806             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
807             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
808             usual time units ms, s, min, h and so on may be used (see
809             L<systemd.time(7)> for
810             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
811             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
812             implied. Also, note that the effective granularity of the limits might influence their
813             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
814             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
815             syntaxes: if prefixed with C<+> or C<->, the value is understood as
816             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
817             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
818              
819             Note that most process resource limits configured with these options are per-process, and
820             processes may fork in order to acquire a new set of resources that are accounted independently of the
821             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
822             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
823             controls listed in
824             L<systemd.resource-control(5)>
825             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
826             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
827             powerful (and working) replacement for C<LimitRSS>.
828              
829             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
830             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
831             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
832             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
833             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
834              
835             Resource limits not configured explicitly for a unit default to the value configured in the various
836             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
837             L<systemd-system.conf(5)>, and \x{2013}
838             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
839             services, see below).
840              
841             For system units these resource limits may be chosen freely. When these settings are configured
842             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
843             used to raise the limits above those set for the user manager itself when it was first invoked, as
844             the user's service manager generally lacks the privileges to do so. In user context these
845             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
846             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
847             available configuration mechanisms differ between operating systems, but typically require
848             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
849             setting limits on the system service encapsulating the user's service manager, i.e. the user's
850             instance of C<user\@.service>. After making such changes, make sure to restart the
851             user's service manager.",
852             'type' => 'leaf',
853             'value_type' => 'uniline'
854             },
855             'LimitFSIZE',
856             {
857             'description' => "Set soft and hard limits on various resources for executed processes. See
858             L<setrlimit(2)> for
859             details on the resource limit concept. Resource limits may be specified in two formats: either as
860             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
861             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
862             Use the string C<infinity> to configure no limit on a specific resource. The
863             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
864             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
865             usual time units ms, s, min, h and so on may be used (see
866             L<systemd.time(7)> for
867             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
868             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
869             implied. Also, note that the effective granularity of the limits might influence their
870             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
871             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
872             syntaxes: if prefixed with C<+> or C<->, the value is understood as
873             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
874             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
875              
876             Note that most process resource limits configured with these options are per-process, and
877             processes may fork in order to acquire a new set of resources that are accounted independently of the
878             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
879             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
880             controls listed in
881             L<systemd.resource-control(5)>
882             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
883             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
884             powerful (and working) replacement for C<LimitRSS>.
885              
886             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
887             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
888             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
889             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
890             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
891              
892             Resource limits not configured explicitly for a unit default to the value configured in the various
893             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
894             L<systemd-system.conf(5)>, and \x{2013}
895             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
896             services, see below).
897              
898             For system units these resource limits may be chosen freely. When these settings are configured
899             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
900             used to raise the limits above those set for the user manager itself when it was first invoked, as
901             the user's service manager generally lacks the privileges to do so. In user context these
902             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
903             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
904             available configuration mechanisms differ between operating systems, but typically require
905             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
906             setting limits on the system service encapsulating the user's service manager, i.e. the user's
907             instance of C<user\@.service>. After making such changes, make sure to restart the
908             user's service manager.",
909             'type' => 'leaf',
910             'value_type' => 'uniline'
911             },
912             'LimitDATA',
913             {
914             'description' => "Set soft and hard limits on various resources for executed processes. See
915             L<setrlimit(2)> for
916             details on the resource limit concept. Resource limits may be specified in two formats: either as
917             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
918             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
919             Use the string C<infinity> to configure no limit on a specific resource. The
920             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
921             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
922             usual time units ms, s, min, h and so on may be used (see
923             L<systemd.time(7)> for
924             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
925             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
926             implied. Also, note that the effective granularity of the limits might influence their
927             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
928             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
929             syntaxes: if prefixed with C<+> or C<->, the value is understood as
930             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
931             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
932              
933             Note that most process resource limits configured with these options are per-process, and
934             processes may fork in order to acquire a new set of resources that are accounted independently of the
935             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
936             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
937             controls listed in
938             L<systemd.resource-control(5)>
939             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
940             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
941             powerful (and working) replacement for C<LimitRSS>.
942              
943             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
944             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
945             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
946             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
947             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
948              
949             Resource limits not configured explicitly for a unit default to the value configured in the various
950             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
951             L<systemd-system.conf(5)>, and \x{2013}
952             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
953             services, see below).
954              
955             For system units these resource limits may be chosen freely. When these settings are configured
956             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
957             used to raise the limits above those set for the user manager itself when it was first invoked, as
958             the user's service manager generally lacks the privileges to do so. In user context these
959             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
960             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
961             available configuration mechanisms differ between operating systems, but typically require
962             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
963             setting limits on the system service encapsulating the user's service manager, i.e. the user's
964             instance of C<user\@.service>. After making such changes, make sure to restart the
965             user's service manager.",
966             'type' => 'leaf',
967             'value_type' => 'uniline'
968             },
969             'LimitSTACK',
970             {
971             'description' => "Set soft and hard limits on various resources for executed processes. See
972             L<setrlimit(2)> for
973             details on the resource limit concept. Resource limits may be specified in two formats: either as
974             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
975             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
976             Use the string C<infinity> to configure no limit on a specific resource. The
977             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
978             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
979             usual time units ms, s, min, h and so on may be used (see
980             L<systemd.time(7)> for
981             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
982             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
983             implied. Also, note that the effective granularity of the limits might influence their
984             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
985             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
986             syntaxes: if prefixed with C<+> or C<->, the value is understood as
987             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
988             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
989              
990             Note that most process resource limits configured with these options are per-process, and
991             processes may fork in order to acquire a new set of resources that are accounted independently of the
992             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
993             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
994             controls listed in
995             L<systemd.resource-control(5)>
996             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
997             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
998             powerful (and working) replacement for C<LimitRSS>.
999              
1000             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1001             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1002             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1003             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1004             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1005              
1006             Resource limits not configured explicitly for a unit default to the value configured in the various
1007             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1008             L<systemd-system.conf(5)>, and \x{2013}
1009             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1010             services, see below).
1011              
1012             For system units these resource limits may be chosen freely. When these settings are configured
1013             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1014             used to raise the limits above those set for the user manager itself when it was first invoked, as
1015             the user's service manager generally lacks the privileges to do so. In user context these
1016             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1017             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1018             available configuration mechanisms differ between operating systems, but typically require
1019             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1020             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1021             instance of C<user\@.service>. After making such changes, make sure to restart the
1022             user's service manager.",
1023             'type' => 'leaf',
1024             'value_type' => 'uniline'
1025             },
1026             'LimitCORE',
1027             {
1028             'description' => "Set soft and hard limits on various resources for executed processes. See
1029             L<setrlimit(2)> for
1030             details on the resource limit concept. Resource limits may be specified in two formats: either as
1031             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1032             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1033             Use the string C<infinity> to configure no limit on a specific resource. The
1034             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1035             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1036             usual time units ms, s, min, h and so on may be used (see
1037             L<systemd.time(7)> for
1038             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1039             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1040             implied. Also, note that the effective granularity of the limits might influence their
1041             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1042             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1043             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1044             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1045             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1046              
1047             Note that most process resource limits configured with these options are per-process, and
1048             processes may fork in order to acquire a new set of resources that are accounted independently of the
1049             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1050             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1051             controls listed in
1052             L<systemd.resource-control(5)>
1053             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1054             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1055             powerful (and working) replacement for C<LimitRSS>.
1056              
1057             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1058             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1059             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1060             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1061             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1062              
1063             Resource limits not configured explicitly for a unit default to the value configured in the various
1064             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1065             L<systemd-system.conf(5)>, and \x{2013}
1066             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1067             services, see below).
1068              
1069             For system units these resource limits may be chosen freely. When these settings are configured
1070             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1071             used to raise the limits above those set for the user manager itself when it was first invoked, as
1072             the user's service manager generally lacks the privileges to do so. In user context these
1073             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1074             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1075             available configuration mechanisms differ between operating systems, but typically require
1076             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1077             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1078             instance of C<user\@.service>. After making such changes, make sure to restart the
1079             user's service manager.",
1080             'type' => 'leaf',
1081             'value_type' => 'uniline'
1082             },
1083             'LimitRSS',
1084             {
1085             'description' => "Set soft and hard limits on various resources for executed processes. See
1086             L<setrlimit(2)> for
1087             details on the resource limit concept. Resource limits may be specified in two formats: either as
1088             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1089             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1090             Use the string C<infinity> to configure no limit on a specific resource. The
1091             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1092             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1093             usual time units ms, s, min, h and so on may be used (see
1094             L<systemd.time(7)> for
1095             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1096             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1097             implied. Also, note that the effective granularity of the limits might influence their
1098             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1099             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1100             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1101             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1102             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1103              
1104             Note that most process resource limits configured with these options are per-process, and
1105             processes may fork in order to acquire a new set of resources that are accounted independently of the
1106             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1107             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1108             controls listed in
1109             L<systemd.resource-control(5)>
1110             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1111             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1112             powerful (and working) replacement for C<LimitRSS>.
1113              
1114             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1115             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1116             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1117             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1118             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1119              
1120             Resource limits not configured explicitly for a unit default to the value configured in the various
1121             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1122             L<systemd-system.conf(5)>, and \x{2013}
1123             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1124             services, see below).
1125              
1126             For system units these resource limits may be chosen freely. When these settings are configured
1127             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1128             used to raise the limits above those set for the user manager itself when it was first invoked, as
1129             the user's service manager generally lacks the privileges to do so. In user context these
1130             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1131             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1132             available configuration mechanisms differ between operating systems, but typically require
1133             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1134             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1135             instance of C<user\@.service>. After making such changes, make sure to restart the
1136             user's service manager.",
1137             'type' => 'leaf',
1138             'value_type' => 'uniline'
1139             },
1140             'LimitNOFILE',
1141             {
1142             'description' => "Set soft and hard limits on various resources for executed processes. See
1143             L<setrlimit(2)> for
1144             details on the resource limit concept. Resource limits may be specified in two formats: either as
1145             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1146             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1147             Use the string C<infinity> to configure no limit on a specific resource. The
1148             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1149             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1150             usual time units ms, s, min, h and so on may be used (see
1151             L<systemd.time(7)> for
1152             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1153             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1154             implied. Also, note that the effective granularity of the limits might influence their
1155             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1156             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1157             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1158             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1159             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1160              
1161             Note that most process resource limits configured with these options are per-process, and
1162             processes may fork in order to acquire a new set of resources that are accounted independently of the
1163             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1164             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1165             controls listed in
1166             L<systemd.resource-control(5)>
1167             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1168             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1169             powerful (and working) replacement for C<LimitRSS>.
1170              
1171             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1172             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1173             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1174             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1175             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1176              
1177             Resource limits not configured explicitly for a unit default to the value configured in the various
1178             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1179             L<systemd-system.conf(5)>, and \x{2013}
1180             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1181             services, see below).
1182              
1183             For system units these resource limits may be chosen freely. When these settings are configured
1184             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1185             used to raise the limits above those set for the user manager itself when it was first invoked, as
1186             the user's service manager generally lacks the privileges to do so. In user context these
1187             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1188             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1189             available configuration mechanisms differ between operating systems, but typically require
1190             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1191             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1192             instance of C<user\@.service>. After making such changes, make sure to restart the
1193             user's service manager.",
1194             'type' => 'leaf',
1195             'value_type' => 'uniline'
1196             },
1197             'LimitAS',
1198             {
1199             'description' => "Set soft and hard limits on various resources for executed processes. See
1200             L<setrlimit(2)> for
1201             details on the resource limit concept. Resource limits may be specified in two formats: either as
1202             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1203             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1204             Use the string C<infinity> to configure no limit on a specific resource. The
1205             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1206             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1207             usual time units ms, s, min, h and so on may be used (see
1208             L<systemd.time(7)> for
1209             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1210             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1211             implied. Also, note that the effective granularity of the limits might influence their
1212             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1213             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1214             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1215             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1216             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1217              
1218             Note that most process resource limits configured with these options are per-process, and
1219             processes may fork in order to acquire a new set of resources that are accounted independently of the
1220             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1221             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1222             controls listed in
1223             L<systemd.resource-control(5)>
1224             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1225             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1226             powerful (and working) replacement for C<LimitRSS>.
1227              
1228             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1229             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1230             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1231             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1232             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1233              
1234             Resource limits not configured explicitly for a unit default to the value configured in the various
1235             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1236             L<systemd-system.conf(5)>, and \x{2013}
1237             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1238             services, see below).
1239              
1240             For system units these resource limits may be chosen freely. When these settings are configured
1241             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1242             used to raise the limits above those set for the user manager itself when it was first invoked, as
1243             the user's service manager generally lacks the privileges to do so. In user context these
1244             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1245             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1246             available configuration mechanisms differ between operating systems, but typically require
1247             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1248             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1249             instance of C<user\@.service>. After making such changes, make sure to restart the
1250             user's service manager.",
1251             'type' => 'leaf',
1252             'value_type' => 'uniline'
1253             },
1254             'LimitNPROC',
1255             {
1256             'description' => "Set soft and hard limits on various resources for executed processes. See
1257             L<setrlimit(2)> for
1258             details on the resource limit concept. Resource limits may be specified in two formats: either as
1259             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1260             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1261             Use the string C<infinity> to configure no limit on a specific resource. The
1262             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1263             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1264             usual time units ms, s, min, h and so on may be used (see
1265             L<systemd.time(7)> for
1266             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1267             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1268             implied. Also, note that the effective granularity of the limits might influence their
1269             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1270             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1271             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1272             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1273             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1274              
1275             Note that most process resource limits configured with these options are per-process, and
1276             processes may fork in order to acquire a new set of resources that are accounted independently of the
1277             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1278             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1279             controls listed in
1280             L<systemd.resource-control(5)>
1281             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1282             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1283             powerful (and working) replacement for C<LimitRSS>.
1284              
1285             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1286             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1287             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1288             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1289             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1290              
1291             Resource limits not configured explicitly for a unit default to the value configured in the various
1292             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1293             L<systemd-system.conf(5)>, and \x{2013}
1294             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1295             services, see below).
1296              
1297             For system units these resource limits may be chosen freely. When these settings are configured
1298             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1299             used to raise the limits above those set for the user manager itself when it was first invoked, as
1300             the user's service manager generally lacks the privileges to do so. In user context these
1301             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1302             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1303             available configuration mechanisms differ between operating systems, but typically require
1304             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1305             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1306             instance of C<user\@.service>. After making such changes, make sure to restart the
1307             user's service manager.",
1308             'type' => 'leaf',
1309             'value_type' => 'uniline'
1310             },
1311             'LimitMEMLOCK',
1312             {
1313             'description' => "Set soft and hard limits on various resources for executed processes. See
1314             L<setrlimit(2)> for
1315             details on the resource limit concept. Resource limits may be specified in two formats: either as
1316             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1317             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1318             Use the string C<infinity> to configure no limit on a specific resource. The
1319             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1320             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1321             usual time units ms, s, min, h and so on may be used (see
1322             L<systemd.time(7)> for
1323             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1324             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1325             implied. Also, note that the effective granularity of the limits might influence their
1326             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1327             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1328             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1329             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1330             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1331              
1332             Note that most process resource limits configured with these options are per-process, and
1333             processes may fork in order to acquire a new set of resources that are accounted independently of the
1334             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1335             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1336             controls listed in
1337             L<systemd.resource-control(5)>
1338             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1339             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1340             powerful (and working) replacement for C<LimitRSS>.
1341              
1342             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1343             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1344             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1345             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1346             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1347              
1348             Resource limits not configured explicitly for a unit default to the value configured in the various
1349             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1350             L<systemd-system.conf(5)>, and \x{2013}
1351             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1352             services, see below).
1353              
1354             For system units these resource limits may be chosen freely. When these settings are configured
1355             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1356             used to raise the limits above those set for the user manager itself when it was first invoked, as
1357             the user's service manager generally lacks the privileges to do so. In user context these
1358             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1359             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1360             available configuration mechanisms differ between operating systems, but typically require
1361             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1362             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1363             instance of C<user\@.service>. After making such changes, make sure to restart the
1364             user's service manager.",
1365             'type' => 'leaf',
1366             'value_type' => 'uniline'
1367             },
1368             'LimitLOCKS',
1369             {
1370             'description' => "Set soft and hard limits on various resources for executed processes. See
1371             L<setrlimit(2)> for
1372             details on the resource limit concept. Resource limits may be specified in two formats: either as
1373             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1374             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1375             Use the string C<infinity> to configure no limit on a specific resource. The
1376             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1377             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1378             usual time units ms, s, min, h and so on may be used (see
1379             L<systemd.time(7)> for
1380             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1381             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1382             implied. Also, note that the effective granularity of the limits might influence their
1383             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1384             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1385             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1386             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1387             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1388              
1389             Note that most process resource limits configured with these options are per-process, and
1390             processes may fork in order to acquire a new set of resources that are accounted independently of the
1391             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1392             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1393             controls listed in
1394             L<systemd.resource-control(5)>
1395             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1396             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1397             powerful (and working) replacement for C<LimitRSS>.
1398              
1399             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1400             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1401             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1402             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1403             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1404              
1405             Resource limits not configured explicitly for a unit default to the value configured in the various
1406             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1407             L<systemd-system.conf(5)>, and \x{2013}
1408             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1409             services, see below).
1410              
1411             For system units these resource limits may be chosen freely. When these settings are configured
1412             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1413             used to raise the limits above those set for the user manager itself when it was first invoked, as
1414             the user's service manager generally lacks the privileges to do so. In user context these
1415             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1416             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1417             available configuration mechanisms differ between operating systems, but typically require
1418             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1419             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1420             instance of C<user\@.service>. After making such changes, make sure to restart the
1421             user's service manager.",
1422             'type' => 'leaf',
1423             'value_type' => 'uniline'
1424             },
1425             'LimitSIGPENDING',
1426             {
1427             'description' => "Set soft and hard limits on various resources for executed processes. See
1428             L<setrlimit(2)> for
1429             details on the resource limit concept. Resource limits may be specified in two formats: either as
1430             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1431             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1432             Use the string C<infinity> to configure no limit on a specific resource. The
1433             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1434             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1435             usual time units ms, s, min, h and so on may be used (see
1436             L<systemd.time(7)> for
1437             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1438             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1439             implied. Also, note that the effective granularity of the limits might influence their
1440             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1441             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1442             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1443             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1444             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1445              
1446             Note that most process resource limits configured with these options are per-process, and
1447             processes may fork in order to acquire a new set of resources that are accounted independently of the
1448             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1449             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1450             controls listed in
1451             L<systemd.resource-control(5)>
1452             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1453             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1454             powerful (and working) replacement for C<LimitRSS>.
1455              
1456             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1457             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1458             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1459             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1460             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1461              
1462             Resource limits not configured explicitly for a unit default to the value configured in the various
1463             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1464             L<systemd-system.conf(5)>, and \x{2013}
1465             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1466             services, see below).
1467              
1468             For system units these resource limits may be chosen freely. When these settings are configured
1469             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1470             used to raise the limits above those set for the user manager itself when it was first invoked, as
1471             the user's service manager generally lacks the privileges to do so. In user context these
1472             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1473             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1474             available configuration mechanisms differ between operating systems, but typically require
1475             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1476             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1477             instance of C<user\@.service>. After making such changes, make sure to restart the
1478             user's service manager.",
1479             'type' => 'leaf',
1480             'value_type' => 'uniline'
1481             },
1482             'LimitMSGQUEUE',
1483             {
1484             'description' => "Set soft and hard limits on various resources for executed processes. See
1485             L<setrlimit(2)> for
1486             details on the resource limit concept. Resource limits may be specified in two formats: either as
1487             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1488             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1489             Use the string C<infinity> to configure no limit on a specific resource. The
1490             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1491             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1492             usual time units ms, s, min, h and so on may be used (see
1493             L<systemd.time(7)> for
1494             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1495             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1496             implied. Also, note that the effective granularity of the limits might influence their
1497             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1498             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1499             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1500             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1501             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1502              
1503             Note that most process resource limits configured with these options are per-process, and
1504             processes may fork in order to acquire a new set of resources that are accounted independently of the
1505             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1506             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1507             controls listed in
1508             L<systemd.resource-control(5)>
1509             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1510             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1511             powerful (and working) replacement for C<LimitRSS>.
1512              
1513             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1514             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1515             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1516             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1517             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1518              
1519             Resource limits not configured explicitly for a unit default to the value configured in the various
1520             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1521             L<systemd-system.conf(5)>, and \x{2013}
1522             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1523             services, see below).
1524              
1525             For system units these resource limits may be chosen freely. When these settings are configured
1526             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1527             used to raise the limits above those set for the user manager itself when it was first invoked, as
1528             the user's service manager generally lacks the privileges to do so. In user context these
1529             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1530             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1531             available configuration mechanisms differ between operating systems, but typically require
1532             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1533             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1534             instance of C<user\@.service>. After making such changes, make sure to restart the
1535             user's service manager.",
1536             'type' => 'leaf',
1537             'value_type' => 'uniline'
1538             },
1539             'LimitNICE',
1540             {
1541             'description' => "Set soft and hard limits on various resources for executed processes. See
1542             L<setrlimit(2)> for
1543             details on the resource limit concept. Resource limits may be specified in two formats: either as
1544             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1545             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1546             Use the string C<infinity> to configure no limit on a specific resource. The
1547             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1548             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1549             usual time units ms, s, min, h and so on may be used (see
1550             L<systemd.time(7)> for
1551             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1552             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1553             implied. Also, note that the effective granularity of the limits might influence their
1554             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1555             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1556             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1557             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1558             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1559              
1560             Note that most process resource limits configured with these options are per-process, and
1561             processes may fork in order to acquire a new set of resources that are accounted independently of the
1562             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1563             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1564             controls listed in
1565             L<systemd.resource-control(5)>
1566             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1567             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1568             powerful (and working) replacement for C<LimitRSS>.
1569              
1570             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1571             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1572             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1573             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1574             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1575              
1576             Resource limits not configured explicitly for a unit default to the value configured in the various
1577             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1578             L<systemd-system.conf(5)>, and \x{2013}
1579             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1580             services, see below).
1581              
1582             For system units these resource limits may be chosen freely. When these settings are configured
1583             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1584             used to raise the limits above those set for the user manager itself when it was first invoked, as
1585             the user's service manager generally lacks the privileges to do so. In user context these
1586             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1587             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1588             available configuration mechanisms differ between operating systems, but typically require
1589             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1590             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1591             instance of C<user\@.service>. After making such changes, make sure to restart the
1592             user's service manager.",
1593             'type' => 'leaf',
1594             'value_type' => 'uniline'
1595             },
1596             'LimitRTPRIO',
1597             {
1598             'description' => "Set soft and hard limits on various resources for executed processes. See
1599             L<setrlimit(2)> for
1600             details on the resource limit concept. Resource limits may be specified in two formats: either as
1601             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1602             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1603             Use the string C<infinity> to configure no limit on a specific resource. The
1604             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1605             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1606             usual time units ms, s, min, h and so on may be used (see
1607             L<systemd.time(7)> for
1608             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1609             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1610             implied. Also, note that the effective granularity of the limits might influence their
1611             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1612             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1613             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1614             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1615             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1616              
1617             Note that most process resource limits configured with these options are per-process, and
1618             processes may fork in order to acquire a new set of resources that are accounted independently of the
1619             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1620             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1621             controls listed in
1622             L<systemd.resource-control(5)>
1623             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1624             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1625             powerful (and working) replacement for C<LimitRSS>.
1626              
1627             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1628             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1629             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1630             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1631             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1632              
1633             Resource limits not configured explicitly for a unit default to the value configured in the various
1634             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1635             L<systemd-system.conf(5)>, and \x{2013}
1636             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1637             services, see below).
1638              
1639             For system units these resource limits may be chosen freely. When these settings are configured
1640             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1641             used to raise the limits above those set for the user manager itself when it was first invoked, as
1642             the user's service manager generally lacks the privileges to do so. In user context these
1643             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1644             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1645             available configuration mechanisms differ between operating systems, but typically require
1646             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1647             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1648             instance of C<user\@.service>. After making such changes, make sure to restart the
1649             user's service manager.",
1650             'type' => 'leaf',
1651             'value_type' => 'uniline'
1652             },
1653             'LimitRTTIME',
1654             {
1655             'description' => "Set soft and hard limits on various resources for executed processes. See
1656             L<setrlimit(2)> for
1657             details on the resource limit concept. Resource limits may be specified in two formats: either as
1658             single value to set a specific soft and hard limit to the same value, or as colon-separated pair
1659             C<soft:hard> to set both limits individually (e.g. C<LimitAS=4G:16G>).
1660             Use the string C<infinity> to configure no limit on a specific resource. The
1661             multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits
1662             measured in bytes (e.g. C<LimitAS=16G>). For the limits referring to time values, the
1663             usual time units ms, s, min, h and so on may be used (see
1664             L<systemd.time(7)> for
1665             details). Note that if no time unit is specified for C<LimitCPU> the default unit of
1666             seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
1667             implied. Also, note that the effective granularity of the limits might influence their
1668             enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
1669             implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
1670             syntaxes: if prefixed with C<+> or C<->, the value is understood as
1671             regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
1672             raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).
1673              
1674             Note that most process resource limits configured with these options are per-process, and
1675             processes may fork in order to acquire a new set of resources that are accounted independently of the
1676             original process, and may thus escape limits set. Also note that C<LimitRSS> is not
1677             implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
1678             controls listed in
1679             L<systemd.resource-control(5)>
1680             over these per-process limits, as they apply to services as a whole, may be altered dynamically at
1681             runtime, and are generally more expressive. For example, C<MemoryMax> is a more
1682             powerful (and working) replacement for C<LimitRSS>.
1683              
1684             Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
1685             not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
1686             processes running under the same UID. Please also note that the C<LimitNPROC> will not be
1687             enforced if the service is running as root (and not dropping privileges). Due to these limitations,
1688             C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.
1689              
1690             Resource limits not configured explicitly for a unit default to the value configured in the various
1691             C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
1692             L<systemd-system.conf(5)>, and \x{2013}
1693             if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
1694             services, see below).
1695              
1696             For system units these resource limits may be chosen freely. When these settings are configured
1697             in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
1698             used to raise the limits above those set for the user manager itself when it was first invoked, as
1699             the user's service manager generally lacks the privileges to do so. In user context these
1700             configuration options are hence only useful to lower the limits passed in or to raise the soft limit
1701             to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
1702             available configuration mechanisms differ between operating systems, but typically require
1703             privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
1704             setting limits on the system service encapsulating the user's service manager, i.e. the user's
1705             instance of C<user\@.service>. After making such changes, make sure to restart the
1706             user's service manager.",
1707             'type' => 'leaf',
1708             'value_type' => 'uniline'
1709             },
1710             'UMask',
1711             {
1712             'description' => "Controls the file mode creation mask. Takes an access mode in octal notation. See
1713             L<umask(2)> for
1714             details. Defaults to 0022 for system units. For user units the default value is inherited from the
1715             per-user service manager (whose default is in turn inherited from the system service manager, and
1716             thus typically also is 0022 \x{2014} unless overridden by a PAM module). In order to change the per-user mask
1717             for all user services, consider setting the C<UMask> setting of the user's
1718             C<user\@.service> system service instance. The per-user umask may also be set via
1719             the C<umask> field of a user's L<JSON User
1720             Record|https://systemd.io/USER_RECORD> (for users managed by
1721             L<systemd-homed.service(8)>
1722             this field may be controlled via homectl --umask=). It may also be set via a PAM
1723             module, such as L<pam_umask(8)>.",
1724             'type' => 'leaf',
1725             'value_type' => 'uniline'
1726             },
1727             'CoredumpFilter',
1728             {
1729             'description' => 'Controls which types of memory mappings will be saved if the process dumps core
1730             (using the C</proc/pid/coredump_filter> file). Takes a
1731             whitespace-separated combination of mapping type names or numbers (with the default base 16). Mapping
1732             type names are C<private-anonymous>, C<shared-anonymous>,
1733             C<private-file-backed>, C<shared-file-backed>,
1734             C<elf-headers>, C<private-huge>,
1735             C<shared-huge>, C<private-dax>, C<shared-dax>,
1736             and the special values C<all> (all types) and C<default> (the
1737             kernel default of C<C<private-anonymous>C<shared-anonymous> C<elf-headers>C<private-huge>>). See
1738             L<core(5)>
1739             for the meaning of the mapping types. When specified multiple times, all specified masks are
1740             ORed. When not set, or if the empty value is assigned, the inherited value is not changed.',
1741             'type' => 'leaf',
1742             'value_type' => 'uniline'
1743             },
1744             'KeyringMode',
1745             {
1746             'choice' => [
1747             'inherit',
1748             'private',
1749             'shared'
1750             ],
1751             'description' => 'Controls how the kernel session keyring is set up for the service (see L<session-keyring(7)> for
1752             details on the session keyring). Takes one of C<inherit>, C<private>,
1753             C<shared>. If set to C<inherit> no special keyring setup is done, and the kernel\'s
1754             default behaviour is applied. If C<private> is used a new session keyring is allocated when a
1755             service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for
1756             system services, as this ensures that multiple services running under the same system user ID (in particular
1757             the root user) do not share their key material among each other. If C<shared> is used a new
1758             session keyring is allocated as for C<private>, but the user keyring of the user configured with
1759             C<User> is linked into it, so that keys assigned to the user may be requested by the unit\'s
1760             processes. In this modes multiple units running processes under the same user ID may share key material. Unless
1761             C<inherit> is selected the unique invocation ID for the unit (see below) is added as a protected
1762             key by the name C<invocation_id> to the newly created session keyring. Defaults to
1763             C<private> for services of the system service manager and to C<inherit> for
1764             non-service units and for services of the user service manager.',
1765             'type' => 'leaf',
1766             'value_type' => 'enum'
1767             },
1768             'OOMScoreAdjust',
1769             {
1770             'description' => 'Sets the adjustment value for the Linux kernel\'s Out-Of-Memory (OOM) killer score for
1771             executed processes. Takes an integer between -1000 (to disable OOM killing of processes of this unit)
1772             and 1000 (to make killing of processes of this unit under memory pressure very likely). See L<proc.txt|https://www.kernel.org/doc/Documentation/filesystems/proc.txt> for details. If
1773             not specified defaults to the OOM score adjustment level of the service manager itself, which is
1774             normally at 0.
1775              
1776             Use the C<OOMPolicy> setting of service units to configure how the service
1777             manager shall react to the kernel OOM killer or systemd-oomd terminating a process of the service. See
1778             L<systemd.service(5)>
1779             for details.',
1780             'max' => '1000',
1781             'min' => '-1000',
1782             'type' => 'leaf',
1783             'value_type' => 'integer'
1784             },
1785             'TimerSlackNSec',
1786             {
1787             'description' => 'Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the
1788             accuracy of wake-ups triggered by timers. See
1789             L<prctl(2)> for more
1790             information. Note that in contrast to most other time span definitions this parameter takes an integer value in
1791             nano-seconds if no unit is specified. The usual time units are understood too.',
1792             'type' => 'leaf',
1793             'value_type' => 'uniline'
1794             },
1795             'Personality',
1796             {
1797             'choice' => [
1798             'x86',
1799             'x86-64',
1800             'ppc',
1801             'ppc-le',
1802             'ppc64',
1803             'ppc64-le',
1804             's390',
1805             's390x'
1806             ],
1807             'description' => 'Controls which kernel architecture L<uname(2)> shall report,
1808             when invoked by unit processes. Takes one of the architecture identifiers C<x86>,
1809             C<x86-64>, C<ppc>, C<ppc-le>, C<ppc64>,
1810             C<ppc64-le>, C<s390> or C<s390x>. Which personality
1811             architectures are supported depends on the system architecture. Usually the 64bit versions of the various
1812             system architectures support their immediate 32bit personality architecture counterpart, but no others. For
1813             example, C<x86-64> systems support the C<x86-64> and
1814             C<x86> personalities but no others. The personality feature is useful when running 32-bit
1815             services on a 64-bit host system. If not specified, the personality is left unmodified and thus reflects the
1816             personality of the host system\'s kernel.',
1817             'type' => 'leaf',
1818             'value_type' => 'enum'
1819             },
1820             'IgnoreSIGPIPE',
1821             {
1822             'description' => 'Takes a boolean argument. If true, causes C<SIGPIPE> to be ignored in the
1823             executed process. Defaults to true because C<SIGPIPE> generally is useful only in shell
1824             pipelines.',
1825             'type' => 'leaf',
1826             'value_type' => 'boolean',
1827             'write_as' => [
1828             'no',
1829             'yes'
1830             ]
1831             },
1832             'Nice',
1833             {
1834             'description' => 'Sets the default nice level (scheduling priority) for executed processes. Takes an
1835             integer between -20 (highest priority) and 19 (lowest priority). In case of resource contention,
1836             smaller values mean more resources will be made available to the unit\'s processes, larger values mean
1837             less resources will be made available. See
1838             L<setpriority(2)> for
1839             details.',
1840             'max' => '19',
1841             'min' => '-20',
1842             'type' => 'leaf',
1843             'value_type' => 'integer'
1844             },
1845             'CPUSchedulingPolicy',
1846             {
1847             'choice' => [
1848             'other',
1849             'batch',
1850             'idle',
1851             'fifo',
1852             'rr'
1853             ],
1854             'description' => 'Sets the CPU scheduling policy for executed processes. Takes one of C<other>,
1855             C<batch>, C<idle>, C<fifo> or C<rr>. See
1856             L<sched_setscheduler(2)> for
1857             details.',
1858             'type' => 'leaf',
1859             'value_type' => 'enum'
1860             },
1861             'CPUSchedulingPriority',
1862             {
1863             'description' => 'Sets the CPU scheduling priority for executed processes. The available priority range
1864             depends on the selected CPU scheduling policy (see above). For real-time scheduling policies an
1865             integer between 1 (lowest priority) and 99 (highest priority) can be used. In case of CPU resource
1866             contention, smaller values mean less CPU time is made available to the service, larger values mean
1867             more. See L<sched_setscheduler(2)>
1868             for details.',
1869             'type' => 'leaf',
1870             'value_type' => 'uniline'
1871             },
1872             'CPUSchedulingResetOnFork',
1873             {
1874             'description' => 'Takes a boolean argument. If true, elevated CPU scheduling priorities and policies
1875             will be reset when the executed processes call
1876             L<fork(2)>,
1877             and can hence not leak into child processes. See
1878             L<sched_setscheduler(2)>
1879             for details. Defaults to false.',
1880             'type' => 'leaf',
1881             'value_type' => 'boolean',
1882             'write_as' => [
1883             'no',
1884             'yes'
1885             ]
1886             },
1887             'CPUAffinity',
1888             {
1889             'cargo' => {
1890             'type' => 'leaf',
1891             'value_type' => 'uniline'
1892             },
1893             'description' => 'Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges
1894             separated by either whitespace or commas. Alternatively, takes a special "numa" value in which case systemd
1895             automatically derives allowed CPU range based on the value of C<NUMAMask> option. CPU ranges
1896             are specified by the lower and upper CPU indices separated by a dash. This option may be specified more than
1897             once, in which case the specified CPU affinity masks are merged. If the empty string is assigned, the mask
1898             is reset, all assignments prior to this will have no effect. See
1899             L<sched_setaffinity(2)> for
1900             details.',
1901             'type' => 'list'
1902             },
1903             'NUMAPolicy',
1904             {
1905             'description' => 'Controls the NUMA memory policy of the executed processes. Takes a policy type, one of:
1906             C<default>, C<preferred>, C<bind>, C<interleave> and
1907             C<local>. A list of NUMA nodes that should be associated with the policy must be specified
1908             in C<NUMAMask>. For more details on each policy please see,
1909             L<set_mempolicy(2)>. For overall
1910             overview of NUMA support in Linux see,
1911             L<numa(7)>.
1912             ',
1913             'type' => 'leaf',
1914             'value_type' => 'uniline'
1915             },
1916             'NUMAMask',
1917             {
1918             'description' => 'Controls the NUMA node list which will be applied alongside with selected NUMA policy.
1919             Takes a list of NUMA nodes and has the same syntax as a list of CPUs for C<CPUAffinity>
1920             option or special "all" value which will include all available NUMA nodes in the mask. Note that the list
1921             of NUMA nodes is not required for C<default> and C<local>
1922             policies and for C<preferred> policy we expect a single NUMA node.',
1923             'type' => 'leaf',
1924             'value_type' => 'uniline'
1925             },
1926             'IOSchedulingClass',
1927             {
1928             'choice' => [
1929             '0',
1930             '1',
1931             '2',
1932             '3',
1933             'none',
1934             'realtime',
1935             'best-effort',
1936             'idle'
1937             ],
1938             'description' => 'Sets the I/O scheduling class for executed processes. Takes one of the strings
1939             C<realtime>, C<best-effort> or C<idle>. The kernel\'s
1940             default scheduling class is C<best-effort> at a priority of 4. If the empty string is
1941             assigned to this option, all prior assignments to both C<IOSchedulingClass> and
1942             C<IOSchedulingPriority> have no effect. See
1943             L<ioprio_set(2)> for
1944             details.',
1945             'type' => 'leaf',
1946             'value_type' => 'enum'
1947             },
1948             'IOSchedulingPriority',
1949             {
1950             'description' => 'Sets the I/O scheduling priority for executed processes. Takes an integer between 0
1951             (highest priority) and 7 (lowest priority). In case of I/O contention, smaller values mean more I/O
1952             bandwidth is made available to the unit\'s processes, larger values mean less bandwidth. The available
1953             priorities depend on the selected I/O scheduling class (see above). If the empty string is assigned
1954             to this option, all prior assignments to both C<IOSchedulingClass> and
1955             C<IOSchedulingPriority> have no effect. For the kernel\'s default scheduling class
1956             (C<best-effort>) this defaults to 4. See
1957             L<ioprio_set(2)> for
1958             details.',
1959             'max' => '7',
1960             'min' => '0',
1961             'type' => 'leaf',
1962             'upstream_default' => '4',
1963             'value_type' => 'integer'
1964             },
1965             'ProtectSystem',
1966             {
1967             'choice' => [
1968             'no',
1969             'yes',
1970             'full',
1971             'strict'
1972             ],
1973             'description' => 'Takes a boolean argument or the special values C<full> or
1974             C<strict>. If true, mounts the C</usr/> and the boot loader
1975             directories (C</boot> and C</efi>) read-only for processes
1976             invoked by this unit. If set to C<full>, the C</etc/> directory is
1977             mounted read-only, too. If set to C<strict> the entire file system hierarchy is
1978             mounted read-only, except for the API file system subtrees C</dev/>,
1979             C</proc/> and C</sys/> (protect these directories using
1980             C<PrivateDevices>, C<ProtectKernelTunables>,
1981             C<ProtectControlGroups>). This setting ensures that any modification of the vendor-supplied
1982             operating system (and optionally its configuration, and local mounts) is prohibited for the service. It is
1983             recommended to enable this setting for all long-running services, unless they are involved with system updates
1984             or need to modify the operating system in other ways. If this option is used,
1985             C<ReadWritePaths> may be used to exclude specific directories from being made read-only. This
1986             setting is implied if C<DynamicUser> is set. This setting cannot ensure protection in all
1987             cases. In general it has the same limitations as C<ReadOnlyPaths>, see below. Defaults to
1988             off.',
1989             'replace' => {
1990             '0' => 'no',
1991             '1' => 'yes',
1992             'false' => 'no',
1993             'true' => 'yes'
1994             },
1995             'type' => 'leaf',
1996             'value_type' => 'enum'
1997             },
1998             'ProtectHome',
1999             {
2000             'choice' => [
2001             'no',
2002             'yes',
2003             'read-only',
2004             'tmpfs'
2005             ],
2006             'description' => 'Takes a boolean argument or the special values C<read-only> or
2007             C<tmpfs>. If true, the directories C</home/>,
2008             C</root>, and C</run/user> are made inaccessible and empty for
2009             processes invoked by this unit. If set to C<read-only>, the three directories are
2010             made read-only instead. If set to C<tmpfs>, temporary file systems are mounted on the
2011             three directories in read-only mode. The value C<tmpfs> is useful to hide home
2012             directories not relevant to the processes invoked by the unit, while still allowing necessary
2013             directories to be made visible when listed in C<BindPaths> or
2014             C<BindReadOnlyPaths>.
2015              
2016             Setting this to C<yes> is mostly equivalent to set the three directories in
2017             C<InaccessiblePaths>. Similarly, C<read-only> is mostly equivalent to
2018             C<ReadOnlyPaths>, and C<tmpfs> is mostly equivalent to
2019             C<TemporaryFileSystem> with C<:ro>.
2020              
2021             It is recommended to enable this setting for all long-running services (in particular
2022             network-facing ones), to ensure they cannot get access to private user data, unless the services
2023             actually require access to the user\'s private data. This setting is implied if
2024             C<DynamicUser> is set. This setting cannot ensure protection in all cases. In
2025             general it has the same limitations as C<ReadOnlyPaths>, see below.',
2026             'replace' => {
2027             '0' => 'no',
2028             '1' => 'yes',
2029             'false' => 'no',
2030             'true' => 'yes'
2031             },
2032             'type' => 'leaf',
2033             'value_type' => 'enum'
2034             },
2035             'RuntimeDirectory',
2036             {
2037             'description' => 'These options take a whitespace-separated list of directory names. The specified
2038             directory names must be relative, and may not include C<..>. If set, when the unit is
2039             started, one or more directories by the specified names will be created (including their parents)
2040             below the locations defined in the following table. Also, the corresponding environment variable will
2041             be defined with the full paths of the directories. If multiple directories are set, then in the
2042             environment variable the paths are concatenated with colon (C<:>).
2043              
2044             In case of C<RuntimeDirectory> the innermost subdirectories are removed when
2045             the unit is stopped. It is possible to preserve the specified directories in this case if
2046             C<RuntimeDirectoryPreserve> is configured to C<restart> or
2047             C<yes> (see below). The directories specified with C<StateDirectory>,
2048             C<CacheDirectory>, C<LogsDirectory>,
2049             C<ConfigurationDirectory> are not removed when the unit is stopped.
2050              
2051             Except in case of C<ConfigurationDirectory>, the innermost specified directories will be
2052             owned by the user and group specified in C<User> and C<Group>. If the
2053             specified directories already exist and their owning user or group do not match the configured ones, all files
2054             and directories below the specified directories as well as the directories themselves will have their file
2055             ownership recursively changed to match what is configured. As an optimization, if the specified directories are
2056             already owned by the right user and group, files and directories below of them are left as-is, even if they do
2057             not match what is requested. The innermost specified directories will have their access mode adjusted to the
2058             what is specified in C<RuntimeDirectoryMode>, C<StateDirectoryMode>,
2059             C<CacheDirectoryMode>, C<LogsDirectoryMode> and
2060             C<ConfigurationDirectoryMode>.
2061              
2062             These options imply C<BindPaths> for the specified paths. When combined with
2063             C<RootDirectory> or C<RootImage> these paths always reside on the host and
2064             are mounted from there into the unit\'s file system namespace.
2065              
2066             If C<DynamicUser> is used, the logic for C<CacheDirectory>,
2067             C<LogsDirectory> and C<StateDirectory> is slightly altered: the directories are created below
2068             C</var/cache/private>, C</var/log/private> and C</var/lib/private>,
2069             respectively, which are host directories made inaccessible to
2070             unprivileged users, which ensures that access to these directories cannot be gained through dynamic
2071             user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
2072             perspective of the host and from inside the unit, the relevant directories hence always appear
2073             directly below C</var/cache>, C</var/log> and
2074             C</var/lib>.
2075              
2076             Use C<RuntimeDirectory> to manage one or more runtime directories for the unit and bind
2077             their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create
2078             runtime directories in C</run/> due to lack of privileges, and to make sure the runtime
2079             directory is cleaned up automatically after use. For runtime directories that require more complex or different
2080             configuration or lifetime guarantees, please consider using
2081             L<tmpfiles.d(5)>.
2082              
2083             C<RuntimeDirectory>, C<StateDirectory>, C<CacheDirectory>
2084             and C<LogsDirectory> optionally support a second parameter, separated by C<:>.
2085             The second parameter will be interpreted as a destination path that will be created as a symlink to the directory.
2086             The symlinks will be created after any C<BindPaths> or C<TemporaryFileSystem>
2087             options have been set up, to make ephemeral symlinking possible. The same source can have multiple symlinks, by
2088             using the same first parameter, but a different second parameter.',
2089             'type' => 'leaf',
2090             'value_type' => 'uniline'
2091             },
2092             'StateDirectory',
2093             {
2094             'description' => 'These options take a whitespace-separated list of directory names. The specified
2095             directory names must be relative, and may not include C<..>. If set, when the unit is
2096             started, one or more directories by the specified names will be created (including their parents)
2097             below the locations defined in the following table. Also, the corresponding environment variable will
2098             be defined with the full paths of the directories. If multiple directories are set, then in the
2099             environment variable the paths are concatenated with colon (C<:>).
2100              
2101             In case of C<RuntimeDirectory> the innermost subdirectories are removed when
2102             the unit is stopped. It is possible to preserve the specified directories in this case if
2103             C<RuntimeDirectoryPreserve> is configured to C<restart> or
2104             C<yes> (see below). The directories specified with C<StateDirectory>,
2105             C<CacheDirectory>, C<LogsDirectory>,
2106             C<ConfigurationDirectory> are not removed when the unit is stopped.
2107              
2108             Except in case of C<ConfigurationDirectory>, the innermost specified directories will be
2109             owned by the user and group specified in C<User> and C<Group>. If the
2110             specified directories already exist and their owning user or group do not match the configured ones, all files
2111             and directories below the specified directories as well as the directories themselves will have their file
2112             ownership recursively changed to match what is configured. As an optimization, if the specified directories are
2113             already owned by the right user and group, files and directories below of them are left as-is, even if they do
2114             not match what is requested. The innermost specified directories will have their access mode adjusted to the
2115             what is specified in C<RuntimeDirectoryMode>, C<StateDirectoryMode>,
2116             C<CacheDirectoryMode>, C<LogsDirectoryMode> and
2117             C<ConfigurationDirectoryMode>.
2118              
2119             These options imply C<BindPaths> for the specified paths. When combined with
2120             C<RootDirectory> or C<RootImage> these paths always reside on the host and
2121             are mounted from there into the unit\'s file system namespace.
2122              
2123             If C<DynamicUser> is used, the logic for C<CacheDirectory>,
2124             C<LogsDirectory> and C<StateDirectory> is slightly altered: the directories are created below
2125             C</var/cache/private>, C</var/log/private> and C</var/lib/private>,
2126             respectively, which are host directories made inaccessible to
2127             unprivileged users, which ensures that access to these directories cannot be gained through dynamic
2128             user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
2129             perspective of the host and from inside the unit, the relevant directories hence always appear
2130             directly below C</var/cache>, C</var/log> and
2131             C</var/lib>.
2132              
2133             Use C<RuntimeDirectory> to manage one or more runtime directories for the unit and bind
2134             their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create
2135             runtime directories in C</run/> due to lack of privileges, and to make sure the runtime
2136             directory is cleaned up automatically after use. For runtime directories that require more complex or different
2137             configuration or lifetime guarantees, please consider using
2138             L<tmpfiles.d(5)>.
2139              
2140             C<RuntimeDirectory>, C<StateDirectory>, C<CacheDirectory>
2141             and C<LogsDirectory> optionally support a second parameter, separated by C<:>.
2142             The second parameter will be interpreted as a destination path that will be created as a symlink to the directory.
2143             The symlinks will be created after any C<BindPaths> or C<TemporaryFileSystem>
2144             options have been set up, to make ephemeral symlinking possible. The same source can have multiple symlinks, by
2145             using the same first parameter, but a different second parameter.',
2146             'type' => 'leaf',
2147             'value_type' => 'uniline'
2148             },
2149             'CacheDirectory',
2150             {
2151             'description' => 'These options take a whitespace-separated list of directory names. The specified
2152             directory names must be relative, and may not include C<..>. If set, when the unit is
2153             started, one or more directories by the specified names will be created (including their parents)
2154             below the locations defined in the following table. Also, the corresponding environment variable will
2155             be defined with the full paths of the directories. If multiple directories are set, then in the
2156             environment variable the paths are concatenated with colon (C<:>).
2157              
2158             In case of C<RuntimeDirectory> the innermost subdirectories are removed when
2159             the unit is stopped. It is possible to preserve the specified directories in this case if
2160             C<RuntimeDirectoryPreserve> is configured to C<restart> or
2161             C<yes> (see below). The directories specified with C<StateDirectory>,
2162             C<CacheDirectory>, C<LogsDirectory>,
2163             C<ConfigurationDirectory> are not removed when the unit is stopped.
2164              
2165             Except in case of C<ConfigurationDirectory>, the innermost specified directories will be
2166             owned by the user and group specified in C<User> and C<Group>. If the
2167             specified directories already exist and their owning user or group do not match the configured ones, all files
2168             and directories below the specified directories as well as the directories themselves will have their file
2169             ownership recursively changed to match what is configured. As an optimization, if the specified directories are
2170             already owned by the right user and group, files and directories below of them are left as-is, even if they do
2171             not match what is requested. The innermost specified directories will have their access mode adjusted to the
2172             what is specified in C<RuntimeDirectoryMode>, C<StateDirectoryMode>,
2173             C<CacheDirectoryMode>, C<LogsDirectoryMode> and
2174             C<ConfigurationDirectoryMode>.
2175              
2176             These options imply C<BindPaths> for the specified paths. When combined with
2177             C<RootDirectory> or C<RootImage> these paths always reside on the host and
2178             are mounted from there into the unit\'s file system namespace.
2179              
2180             If C<DynamicUser> is used, the logic for C<CacheDirectory>,
2181             C<LogsDirectory> and C<StateDirectory> is slightly altered: the directories are created below
2182             C</var/cache/private>, C</var/log/private> and C</var/lib/private>,
2183             respectively, which are host directories made inaccessible to
2184             unprivileged users, which ensures that access to these directories cannot be gained through dynamic
2185             user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
2186             perspective of the host and from inside the unit, the relevant directories hence always appear
2187             directly below C</var/cache>, C</var/log> and
2188             C</var/lib>.
2189              
2190             Use C<RuntimeDirectory> to manage one or more runtime directories for the unit and bind
2191             their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create
2192             runtime directories in C</run/> due to lack of privileges, and to make sure the runtime
2193             directory is cleaned up automatically after use. For runtime directories that require more complex or different
2194             configuration or lifetime guarantees, please consider using
2195             L<tmpfiles.d(5)>.
2196              
2197             C<RuntimeDirectory>, C<StateDirectory>, C<CacheDirectory>
2198             and C<LogsDirectory> optionally support a second parameter, separated by C<:>.
2199             The second parameter will be interpreted as a destination path that will be created as a symlink to the directory.
2200             The symlinks will be created after any C<BindPaths> or C<TemporaryFileSystem>
2201             options have been set up, to make ephemeral symlinking possible. The same source can have multiple symlinks, by
2202             using the same first parameter, but a different second parameter.',
2203             'type' => 'leaf',
2204             'value_type' => 'uniline'
2205             },
2206             'LogsDirectory',
2207             {
2208             'description' => 'These options take a whitespace-separated list of directory names. The specified
2209             directory names must be relative, and may not include C<..>. If set, when the unit is
2210             started, one or more directories by the specified names will be created (including their parents)
2211             below the locations defined in the following table. Also, the corresponding environment variable will
2212             be defined with the full paths of the directories. If multiple directories are set, then in the
2213             environment variable the paths are concatenated with colon (C<:>).
2214              
2215             In case of C<RuntimeDirectory> the innermost subdirectories are removed when
2216             the unit is stopped. It is possible to preserve the specified directories in this case if
2217             C<RuntimeDirectoryPreserve> is configured to C<restart> or
2218             C<yes> (see below). The directories specified with C<StateDirectory>,
2219             C<CacheDirectory>, C<LogsDirectory>,
2220             C<ConfigurationDirectory> are not removed when the unit is stopped.
2221              
2222             Except in case of C<ConfigurationDirectory>, the innermost specified directories will be
2223             owned by the user and group specified in C<User> and C<Group>. If the
2224             specified directories already exist and their owning user or group do not match the configured ones, all files
2225             and directories below the specified directories as well as the directories themselves will have their file
2226             ownership recursively changed to match what is configured. As an optimization, if the specified directories are
2227             already owned by the right user and group, files and directories below of them are left as-is, even if they do
2228             not match what is requested. The innermost specified directories will have their access mode adjusted to the
2229             what is specified in C<RuntimeDirectoryMode>, C<StateDirectoryMode>,
2230             C<CacheDirectoryMode>, C<LogsDirectoryMode> and
2231             C<ConfigurationDirectoryMode>.
2232              
2233             These options imply C<BindPaths> for the specified paths. When combined with
2234             C<RootDirectory> or C<RootImage> these paths always reside on the host and
2235             are mounted from there into the unit\'s file system namespace.
2236              
2237             If C<DynamicUser> is used, the logic for C<CacheDirectory>,
2238             C<LogsDirectory> and C<StateDirectory> is slightly altered: the directories are created below
2239             C</var/cache/private>, C</var/log/private> and C</var/lib/private>,
2240             respectively, which are host directories made inaccessible to
2241             unprivileged users, which ensures that access to these directories cannot be gained through dynamic
2242             user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
2243             perspective of the host and from inside the unit, the relevant directories hence always appear
2244             directly below C</var/cache>, C</var/log> and
2245             C</var/lib>.
2246              
2247             Use C<RuntimeDirectory> to manage one or more runtime directories for the unit and bind
2248             their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create
2249             runtime directories in C</run/> due to lack of privileges, and to make sure the runtime
2250             directory is cleaned up automatically after use. For runtime directories that require more complex or different
2251             configuration or lifetime guarantees, please consider using
2252             L<tmpfiles.d(5)>.
2253              
2254             C<RuntimeDirectory>, C<StateDirectory>, C<CacheDirectory>
2255             and C<LogsDirectory> optionally support a second parameter, separated by C<:>.
2256             The second parameter will be interpreted as a destination path that will be created as a symlink to the directory.
2257             The symlinks will be created after any C<BindPaths> or C<TemporaryFileSystem>
2258             options have been set up, to make ephemeral symlinking possible. The same source can have multiple symlinks, by
2259             using the same first parameter, but a different second parameter.',
2260             'type' => 'leaf',
2261             'value_type' => 'uniline'
2262             },
2263             'ConfigurationDirectory',
2264             {
2265             'description' => 'These options take a whitespace-separated list of directory names. The specified
2266             directory names must be relative, and may not include C<..>. If set, when the unit is
2267             started, one or more directories by the specified names will be created (including their parents)
2268             below the locations defined in the following table. Also, the corresponding environment variable will
2269             be defined with the full paths of the directories. If multiple directories are set, then in the
2270             environment variable the paths are concatenated with colon (C<:>).
2271              
2272             In case of C<RuntimeDirectory> the innermost subdirectories are removed when
2273             the unit is stopped. It is possible to preserve the specified directories in this case if
2274             C<RuntimeDirectoryPreserve> is configured to C<restart> or
2275             C<yes> (see below). The directories specified with C<StateDirectory>,
2276             C<CacheDirectory>, C<LogsDirectory>,
2277             C<ConfigurationDirectory> are not removed when the unit is stopped.
2278              
2279             Except in case of C<ConfigurationDirectory>, the innermost specified directories will be
2280             owned by the user and group specified in C<User> and C<Group>. If the
2281             specified directories already exist and their owning user or group do not match the configured ones, all files
2282             and directories below the specified directories as well as the directories themselves will have their file
2283             ownership recursively changed to match what is configured. As an optimization, if the specified directories are
2284             already owned by the right user and group, files and directories below of them are left as-is, even if they do
2285             not match what is requested. The innermost specified directories will have their access mode adjusted to the
2286             what is specified in C<RuntimeDirectoryMode>, C<StateDirectoryMode>,
2287             C<CacheDirectoryMode>, C<LogsDirectoryMode> and
2288             C<ConfigurationDirectoryMode>.
2289              
2290             These options imply C<BindPaths> for the specified paths. When combined with
2291             C<RootDirectory> or C<RootImage> these paths always reside on the host and
2292             are mounted from there into the unit\'s file system namespace.
2293              
2294             If C<DynamicUser> is used, the logic for C<CacheDirectory>,
2295             C<LogsDirectory> and C<StateDirectory> is slightly altered: the directories are created below
2296             C</var/cache/private>, C</var/log/private> and C</var/lib/private>,
2297             respectively, which are host directories made inaccessible to
2298             unprivileged users, which ensures that access to these directories cannot be gained through dynamic
2299             user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
2300             perspective of the host and from inside the unit, the relevant directories hence always appear
2301             directly below C</var/cache>, C</var/log> and
2302             C</var/lib>.
2303              
2304             Use C<RuntimeDirectory> to manage one or more runtime directories for the unit and bind
2305             their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create
2306             runtime directories in C</run/> due to lack of privileges, and to make sure the runtime
2307             directory is cleaned up automatically after use. For runtime directories that require more complex or different
2308             configuration or lifetime guarantees, please consider using
2309             L<tmpfiles.d(5)>.
2310              
2311             C<RuntimeDirectory>, C<StateDirectory>, C<CacheDirectory>
2312             and C<LogsDirectory> optionally support a second parameter, separated by C<:>.
2313             The second parameter will be interpreted as a destination path that will be created as a symlink to the directory.
2314             The symlinks will be created after any C<BindPaths> or C<TemporaryFileSystem>
2315             options have been set up, to make ephemeral symlinking possible. The same source can have multiple symlinks, by
2316             using the same first parameter, but a different second parameter.',
2317             'type' => 'leaf',
2318             'value_type' => 'uniline'
2319             },
2320             'RuntimeDirectoryMode',
2321             {
2322             'description' => 'Specifies the access mode of the directories specified in C<RuntimeDirectory>,
2323             C<StateDirectory>, C<CacheDirectory>, C<LogsDirectory>, or
2324             C<ConfigurationDirectory>, respectively, as an octal number. Defaults to
2325             C<0755>. See "Permissions" in L<path_resolution(7)> for a
2326             discussion of the meaning of permission bits.',
2327             'type' => 'leaf',
2328             'value_type' => 'uniline'
2329             },
2330             'StateDirectoryMode',
2331             {
2332             'description' => 'Specifies the access mode of the directories specified in C<RuntimeDirectory>,
2333             C<StateDirectory>, C<CacheDirectory>, C<LogsDirectory>, or
2334             C<ConfigurationDirectory>, respectively, as an octal number. Defaults to
2335             C<0755>. See "Permissions" in L<path_resolution(7)> for a
2336             discussion of the meaning of permission bits.',
2337             'type' => 'leaf',
2338             'value_type' => 'uniline'
2339             },
2340             'CacheDirectoryMode',
2341             {
2342             'description' => 'Specifies the access mode of the directories specified in C<RuntimeDirectory>,
2343             C<StateDirectory>, C<CacheDirectory>, C<LogsDirectory>, or
2344             C<ConfigurationDirectory>, respectively, as an octal number. Defaults to
2345             C<0755>. See "Permissions" in L<path_resolution(7)> for a
2346             discussion of the meaning of permission bits.',
2347             'type' => 'leaf',
2348             'value_type' => 'uniline'
2349             },
2350             'LogsDirectoryMode',
2351             {
2352             'description' => 'Specifies the access mode of the directories specified in C<RuntimeDirectory>,
2353             C<StateDirectory>, C<CacheDirectory>, C<LogsDirectory>, or
2354             C<ConfigurationDirectory>, respectively, as an octal number. Defaults to
2355             C<0755>. See "Permissions" in L<path_resolution(7)> for a
2356             discussion of the meaning of permission bits.',
2357             'type' => 'leaf',
2358             'value_type' => 'uniline'
2359             },
2360             'ConfigurationDirectoryMode',
2361             {
2362             'description' => 'Specifies the access mode of the directories specified in C<RuntimeDirectory>,
2363             C<StateDirectory>, C<CacheDirectory>, C<LogsDirectory>, or
2364             C<ConfigurationDirectory>, respectively, as an octal number. Defaults to
2365             C<0755>. See "Permissions" in L<path_resolution(7)> for a
2366             discussion of the meaning of permission bits.',
2367             'type' => 'leaf',
2368             'value_type' => 'uniline'
2369             },
2370             'RuntimeDirectoryPreserve',
2371             {
2372             'choice' => [
2373             'no',
2374             'yes',
2375             'restart'
2376             ],
2377             'description' => 'Takes a boolean argument or C<restart>. If set to C<no> (the
2378             default), the directories specified in C<RuntimeDirectory> are always removed when the service
2379             stops. If set to C<restart> the directories are preserved when the service is both automatically
2380             and manually restarted. Here, the automatic restart means the operation specified in
2381             C<Restart>, and manual restart means the one triggered by systemctl restart
2382             foo.service. If set to C<yes>, then the directories are not removed when the service is
2383             stopped. Note that since the runtime directory C</run/> is a mount point of
2384             C<tmpfs>, then for system services the directories specified in
2385             C<RuntimeDirectory> are removed when the system is rebooted.',
2386             'replace' => {
2387             '0' => 'no',
2388             '1' => 'yes',
2389             'false' => 'no',
2390             'true' => 'yes'
2391             },
2392             'type' => 'leaf',
2393             'value_type' => 'enum'
2394             },
2395             'TimeoutCleanSec',
2396             {
2397             'description' => "Configures a timeout on the clean-up operation requested through systemctl
2398             clean \x{2026}, see
2399             L<systemctl(1)> for
2400             details. Takes the usual time values and defaults to C<infinity>, i.e. by default
2401             no timeout is applied. If a timeout is configured the clean operation will be aborted forcibly when
2402             the timeout is reached, potentially leaving resources on disk.",
2403             'type' => 'leaf',
2404             'value_type' => 'uniline'
2405             },
2406             'ReadWritePaths',
2407             {
2408             'cargo' => {
2409             'type' => 'leaf',
2410             'value_type' => 'uniline'
2411             },
2412             'description' => 'Sets up a new file system namespace for executed processes. These options may be used
2413             to limit access a process has to the file system. Each setting takes a space-separated list of paths
2414             relative to the host\'s root directory (i.e. the system running the service manager). Note that if
2415             paths contain symlinks, they are resolved relative to the root directory set with
2416             C<RootDirectory>/C<RootImage>.
2417              
2418             Paths listed in C<ReadWritePaths> are accessible from within the namespace
2419             with the same access modes as from outside of it. Paths listed in C<ReadOnlyPaths>
2420             are accessible for reading only, writing will be refused even if the usual file access controls would
2421             permit this. Nest C<ReadWritePaths> inside of C<ReadOnlyPaths> in
2422             order to provide writable subdirectories within read-only directories. Use
2423             C<ReadWritePaths> in order to allow-list specific paths for write access if
2424             C<ProtectSystem=strict> is used.
2425              
2426             Paths listed in C<InaccessiblePaths> will be made inaccessible for processes inside
2427             the namespace along with everything below them in the file system hierarchy. This may be more restrictive than
2428             desired, because it is not possible to nest C<ReadWritePaths>, C<ReadOnlyPaths>,
2429             C<BindPaths>, or C<BindReadOnlyPaths> inside it. For a more flexible option,
2430             see C<TemporaryFileSystem>.
2431              
2432             Content in paths listed in C<NoExecPaths> are not executable even if the usual
2433             file access controls would permit this. Nest C<ExecPaths> inside of
2434             C<NoExecPaths> in order to provide executable content within non-executable
2435             directories.
2436              
2437             Non-directory paths may be specified as well. These options may be specified more than once,
2438             in which case all paths listed will have limited access from within the namespace. If the empty string is
2439             assigned to this option, the specific list is reset, and all prior assignments have no effect.
2440              
2441             Paths in C<ReadWritePaths>, C<ReadOnlyPaths>,
2442             C<InaccessiblePaths>, C<ExecPaths> and
2443             C<NoExecPaths> may be prefixed with C<->, in which case they will be
2444             ignored when they do not exist. If prefixed with C<+> the paths are taken relative to the root
2445             directory of the unit, as configured with C<RootDirectory>/C<RootImage>,
2446             instead of relative to the root directory of the host (see above). When combining C<-> and
2447             C<+> on the same path make sure to specify C<-> first, and C<+>
2448             second.
2449              
2450             Note that these settings will disconnect propagation of mounts from the unit\'s processes to the
2451             host. This means that this setting may not be used for services which shall be able to install mount points in
2452             the main mount namespace. For C<ReadWritePaths> and C<ReadOnlyPaths>
2453             propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the
2454             unit processes\' namespace, and mounts removed on the host also disappear there too. In particular, note that
2455             mount propagation from host to unit will result in unmodified mounts to be created in the unit\'s namespace,
2456             i.e. writable mounts appearing on the host will be writable in the unit\'s namespace too, even when propagated
2457             below a path marked with C<ReadOnlyPaths>! Restricting access with these options hence does
2458             not extend to submounts of a directory that are created later on. This means the lock-down offered by that
2459             setting is not complete, and does not offer full protection.
2460              
2461             Note that the effect of these settings may be undone by privileged processes. In order to set up an
2462             effective sandboxed environment for a unit it is thus recommended to combine these settings with either
2463             C<CapabilityBoundingSet=~CAP_SYS_ADMIN> or
2464             C<SystemCallFilter=~@mount>.
2465              
2466             Simple allow-list example using these directives:
2467              
2468             [Service]
2469             ReadOnlyPaths=/
2470             ReadWritePaths=/var /run
2471             InaccessiblePaths=-/lost+found
2472             NoExecPaths=/
2473             ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64
2474              
2475             ',
2476             'type' => 'list'
2477             },
2478             'ReadOnlyPaths',
2479             {
2480             'cargo' => {
2481             'type' => 'leaf',
2482             'value_type' => 'uniline'
2483             },
2484             'description' => 'Sets up a new file system namespace for executed processes. These options may be used
2485             to limit access a process has to the file system. Each setting takes a space-separated list of paths
2486             relative to the host\'s root directory (i.e. the system running the service manager). Note that if
2487             paths contain symlinks, they are resolved relative to the root directory set with
2488             C<RootDirectory>/C<RootImage>.
2489              
2490             Paths listed in C<ReadWritePaths> are accessible from within the namespace
2491             with the same access modes as from outside of it. Paths listed in C<ReadOnlyPaths>
2492             are accessible for reading only, writing will be refused even if the usual file access controls would
2493             permit this. Nest C<ReadWritePaths> inside of C<ReadOnlyPaths> in
2494             order to provide writable subdirectories within read-only directories. Use
2495             C<ReadWritePaths> in order to allow-list specific paths for write access if
2496             C<ProtectSystem=strict> is used.
2497              
2498             Paths listed in C<InaccessiblePaths> will be made inaccessible for processes inside
2499             the namespace along with everything below them in the file system hierarchy. This may be more restrictive than
2500             desired, because it is not possible to nest C<ReadWritePaths>, C<ReadOnlyPaths>,
2501             C<BindPaths>, or C<BindReadOnlyPaths> inside it. For a more flexible option,
2502             see C<TemporaryFileSystem>.
2503              
2504             Content in paths listed in C<NoExecPaths> are not executable even if the usual
2505             file access controls would permit this. Nest C<ExecPaths> inside of
2506             C<NoExecPaths> in order to provide executable content within non-executable
2507             directories.
2508              
2509             Non-directory paths may be specified as well. These options may be specified more than once,
2510             in which case all paths listed will have limited access from within the namespace. If the empty string is
2511             assigned to this option, the specific list is reset, and all prior assignments have no effect.
2512              
2513             Paths in C<ReadWritePaths>, C<ReadOnlyPaths>,
2514             C<InaccessiblePaths>, C<ExecPaths> and
2515             C<NoExecPaths> may be prefixed with C<->, in which case they will be
2516             ignored when they do not exist. If prefixed with C<+> the paths are taken relative to the root
2517             directory of the unit, as configured with C<RootDirectory>/C<RootImage>,
2518             instead of relative to the root directory of the host (see above). When combining C<-> and
2519             C<+> on the same path make sure to specify C<-> first, and C<+>
2520             second.
2521              
2522             Note that these settings will disconnect propagation of mounts from the unit\'s processes to the
2523             host. This means that this setting may not be used for services which shall be able to install mount points in
2524             the main mount namespace. For C<ReadWritePaths> and C<ReadOnlyPaths>
2525             propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the
2526             unit processes\' namespace, and mounts removed on the host also disappear there too. In particular, note that
2527             mount propagation from host to unit will result in unmodified mounts to be created in the unit\'s namespace,
2528             i.e. writable mounts appearing on the host will be writable in the unit\'s namespace too, even when propagated
2529             below a path marked with C<ReadOnlyPaths>! Restricting access with these options hence does
2530             not extend to submounts of a directory that are created later on. This means the lock-down offered by that
2531             setting is not complete, and does not offer full protection.
2532              
2533             Note that the effect of these settings may be undone by privileged processes. In order to set up an
2534             effective sandboxed environment for a unit it is thus recommended to combine these settings with either
2535             C<CapabilityBoundingSet=~CAP_SYS_ADMIN> or
2536             C<SystemCallFilter=~@mount>.
2537              
2538             Simple allow-list example using these directives:
2539              
2540             [Service]
2541             ReadOnlyPaths=/
2542             ReadWritePaths=/var /run
2543             InaccessiblePaths=-/lost+found
2544             NoExecPaths=/
2545             ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64
2546              
2547             ',
2548             'type' => 'list'
2549             },
2550             'InaccessiblePaths',
2551             {
2552             'cargo' => {
2553             'type' => 'leaf',
2554             'value_type' => 'uniline'
2555             },
2556             'description' => 'Sets up a new file system namespace for executed processes. These options may be used
2557             to limit access a process has to the file system. Each setting takes a space-separated list of paths
2558             relative to the host\'s root directory (i.e. the system running the service manager). Note that if
2559             paths contain symlinks, they are resolved relative to the root directory set with
2560             C<RootDirectory>/C<RootImage>.
2561              
2562             Paths listed in C<ReadWritePaths> are accessible from within the namespace
2563             with the same access modes as from outside of it. Paths listed in C<ReadOnlyPaths>
2564             are accessible for reading only, writing will be refused even if the usual file access controls would
2565             permit this. Nest C<ReadWritePaths> inside of C<ReadOnlyPaths> in
2566             order to provide writable subdirectories within read-only directories. Use
2567             C<ReadWritePaths> in order to allow-list specific paths for write access if
2568             C<ProtectSystem=strict> is used.
2569              
2570             Paths listed in C<InaccessiblePaths> will be made inaccessible for processes inside
2571             the namespace along with everything below them in the file system hierarchy. This may be more restrictive than
2572             desired, because it is not possible to nest C<ReadWritePaths>, C<ReadOnlyPaths>,
2573             C<BindPaths>, or C<BindReadOnlyPaths> inside it. For a more flexible option,
2574             see C<TemporaryFileSystem>.
2575              
2576             Content in paths listed in C<NoExecPaths> are not executable even if the usual
2577             file access controls would permit this. Nest C<ExecPaths> inside of
2578             C<NoExecPaths> in order to provide executable content within non-executable
2579             directories.
2580              
2581             Non-directory paths may be specified as well. These options may be specified more than once,
2582             in which case all paths listed will have limited access from within the namespace. If the empty string is
2583             assigned to this option, the specific list is reset, and all prior assignments have no effect.
2584              
2585             Paths in C<ReadWritePaths>, C<ReadOnlyPaths>,
2586             C<InaccessiblePaths>, C<ExecPaths> and
2587             C<NoExecPaths> may be prefixed with C<->, in which case they will be
2588             ignored when they do not exist. If prefixed with C<+> the paths are taken relative to the root
2589             directory of the unit, as configured with C<RootDirectory>/C<RootImage>,
2590             instead of relative to the root directory of the host (see above). When combining C<-> and
2591             C<+> on the same path make sure to specify C<-> first, and C<+>
2592             second.
2593              
2594             Note that these settings will disconnect propagation of mounts from the unit\'s processes to the
2595             host. This means that this setting may not be used for services which shall be able to install mount points in
2596             the main mount namespace. For C<ReadWritePaths> and C<ReadOnlyPaths>
2597             propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the
2598             unit processes\' namespace, and mounts removed on the host also disappear there too. In particular, note that
2599             mount propagation from host to unit will result in unmodified mounts to be created in the unit\'s namespace,
2600             i.e. writable mounts appearing on the host will be writable in the unit\'s namespace too, even when propagated
2601             below a path marked with C<ReadOnlyPaths>! Restricting access with these options hence does
2602             not extend to submounts of a directory that are created later on. This means the lock-down offered by that
2603             setting is not complete, and does not offer full protection.
2604              
2605             Note that the effect of these settings may be undone by privileged processes. In order to set up an
2606             effective sandboxed environment for a unit it is thus recommended to combine these settings with either
2607             C<CapabilityBoundingSet=~CAP_SYS_ADMIN> or
2608             C<SystemCallFilter=~@mount>.
2609              
2610             Simple allow-list example using these directives:
2611              
2612             [Service]
2613             ReadOnlyPaths=/
2614             ReadWritePaths=/var /run
2615             InaccessiblePaths=-/lost+found
2616             NoExecPaths=/
2617             ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64
2618              
2619             ',
2620             'type' => 'list'
2621             },
2622             'ExecPaths',
2623             {
2624             'cargo' => {
2625             'type' => 'leaf',
2626             'value_type' => 'uniline'
2627             },
2628             'description' => 'Sets up a new file system namespace for executed processes. These options may be used
2629             to limit access a process has to the file system. Each setting takes a space-separated list of paths
2630             relative to the host\'s root directory (i.e. the system running the service manager). Note that if
2631             paths contain symlinks, they are resolved relative to the root directory set with
2632             C<RootDirectory>/C<RootImage>.
2633              
2634             Paths listed in C<ReadWritePaths> are accessible from within the namespace
2635             with the same access modes as from outside of it. Paths listed in C<ReadOnlyPaths>
2636             are accessible for reading only, writing will be refused even if the usual file access controls would
2637             permit this. Nest C<ReadWritePaths> inside of C<ReadOnlyPaths> in
2638             order to provide writable subdirectories within read-only directories. Use
2639             C<ReadWritePaths> in order to allow-list specific paths for write access if
2640             C<ProtectSystem=strict> is used.
2641              
2642             Paths listed in C<InaccessiblePaths> will be made inaccessible for processes inside
2643             the namespace along with everything below them in the file system hierarchy. This may be more restrictive than
2644             desired, because it is not possible to nest C<ReadWritePaths>, C<ReadOnlyPaths>,
2645             C<BindPaths>, or C<BindReadOnlyPaths> inside it. For a more flexible option,
2646             see C<TemporaryFileSystem>.
2647              
2648             Content in paths listed in C<NoExecPaths> are not executable even if the usual
2649             file access controls would permit this. Nest C<ExecPaths> inside of
2650             C<NoExecPaths> in order to provide executable content within non-executable
2651             directories.
2652              
2653             Non-directory paths may be specified as well. These options may be specified more than once,
2654             in which case all paths listed will have limited access from within the namespace. If the empty string is
2655             assigned to this option, the specific list is reset, and all prior assignments have no effect.
2656              
2657             Paths in C<ReadWritePaths>, C<ReadOnlyPaths>,
2658             C<InaccessiblePaths>, C<ExecPaths> and
2659             C<NoExecPaths> may be prefixed with C<->, in which case they will be
2660             ignored when they do not exist. If prefixed with C<+> the paths are taken relative to the root
2661             directory of the unit, as configured with C<RootDirectory>/C<RootImage>,
2662             instead of relative to the root directory of the host (see above). When combining C<-> and
2663             C<+> on the same path make sure to specify C<-> first, and C<+>
2664             second.
2665              
2666             Note that these settings will disconnect propagation of mounts from the unit\'s processes to the
2667             host. This means that this setting may not be used for services which shall be able to install mount points in
2668             the main mount namespace. For C<ReadWritePaths> and C<ReadOnlyPaths>
2669             propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the
2670             unit processes\' namespace, and mounts removed on the host also disappear there too. In particular, note that
2671             mount propagation from host to unit will result in unmodified mounts to be created in the unit\'s namespace,
2672             i.e. writable mounts appearing on the host will be writable in the unit\'s namespace too, even when propagated
2673             below a path marked with C<ReadOnlyPaths>! Restricting access with these options hence does
2674             not extend to submounts of a directory that are created later on. This means the lock-down offered by that
2675             setting is not complete, and does not offer full protection.
2676              
2677             Note that the effect of these settings may be undone by privileged processes. In order to set up an
2678             effective sandboxed environment for a unit it is thus recommended to combine these settings with either
2679             C<CapabilityBoundingSet=~CAP_SYS_ADMIN> or
2680             C<SystemCallFilter=~@mount>.
2681              
2682             Simple allow-list example using these directives:
2683              
2684             [Service]
2685             ReadOnlyPaths=/
2686             ReadWritePaths=/var /run
2687             InaccessiblePaths=-/lost+found
2688             NoExecPaths=/
2689             ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64
2690              
2691             ',
2692             'type' => 'list'
2693             },
2694             'NoExecPaths',
2695             {
2696             'cargo' => {
2697             'type' => 'leaf',
2698             'value_type' => 'uniline'
2699             },
2700             'description' => 'Sets up a new file system namespace for executed processes. These options may be used
2701             to limit access a process has to the file system. Each setting takes a space-separated list of paths
2702             relative to the host\'s root directory (i.e. the system running the service manager). Note that if
2703             paths contain symlinks, they are resolved relative to the root directory set with
2704             C<RootDirectory>/C<RootImage>.
2705              
2706             Paths listed in C<ReadWritePaths> are accessible from within the namespace
2707             with the same access modes as from outside of it. Paths listed in C<ReadOnlyPaths>
2708             are accessible for reading only, writing will be refused even if the usual file access controls would
2709             permit this. Nest C<ReadWritePaths> inside of C<ReadOnlyPaths> in
2710             order to provide writable subdirectories within read-only directories. Use
2711             C<ReadWritePaths> in order to allow-list specific paths for write access if
2712             C<ProtectSystem=strict> is used.
2713              
2714             Paths listed in C<InaccessiblePaths> will be made inaccessible for processes inside
2715             the namespace along with everything below them in the file system hierarchy. This may be more restrictive than
2716             desired, because it is not possible to nest C<ReadWritePaths>, C<ReadOnlyPaths>,
2717             C<BindPaths>, or C<BindReadOnlyPaths> inside it. For a more flexible option,
2718             see C<TemporaryFileSystem>.
2719              
2720             Content in paths listed in C<NoExecPaths> are not executable even if the usual
2721             file access controls would permit this. Nest C<ExecPaths> inside of
2722             C<NoExecPaths> in order to provide executable content within non-executable
2723             directories.
2724              
2725             Non-directory paths may be specified as well. These options may be specified more than once,
2726             in which case all paths listed will have limited access from within the namespace. If the empty string is
2727             assigned to this option, the specific list is reset, and all prior assignments have no effect.
2728              
2729             Paths in C<ReadWritePaths>, C<ReadOnlyPaths>,
2730             C<InaccessiblePaths>, C<ExecPaths> and
2731             C<NoExecPaths> may be prefixed with C<->, in which case they will be
2732             ignored when they do not exist. If prefixed with C<+> the paths are taken relative to the root
2733             directory of the unit, as configured with C<RootDirectory>/C<RootImage>,
2734             instead of relative to the root directory of the host (see above). When combining C<-> and
2735             C<+> on the same path make sure to specify C<-> first, and C<+>
2736             second.
2737              
2738             Note that these settings will disconnect propagation of mounts from the unit\'s processes to the
2739             host. This means that this setting may not be used for services which shall be able to install mount points in
2740             the main mount namespace. For C<ReadWritePaths> and C<ReadOnlyPaths>
2741             propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the
2742             unit processes\' namespace, and mounts removed on the host also disappear there too. In particular, note that
2743             mount propagation from host to unit will result in unmodified mounts to be created in the unit\'s namespace,
2744             i.e. writable mounts appearing on the host will be writable in the unit\'s namespace too, even when propagated
2745             below a path marked with C<ReadOnlyPaths>! Restricting access with these options hence does
2746             not extend to submounts of a directory that are created later on. This means the lock-down offered by that
2747             setting is not complete, and does not offer full protection.
2748              
2749             Note that the effect of these settings may be undone by privileged processes. In order to set up an
2750             effective sandboxed environment for a unit it is thus recommended to combine these settings with either
2751             C<CapabilityBoundingSet=~CAP_SYS_ADMIN> or
2752             C<SystemCallFilter=~@mount>.
2753              
2754             Simple allow-list example using these directives:
2755              
2756             [Service]
2757             ReadOnlyPaths=/
2758             ReadWritePaths=/var /run
2759             InaccessiblePaths=-/lost+found
2760             NoExecPaths=/
2761             ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64
2762              
2763             ',
2764             'type' => 'list'
2765             },
2766             'TemporaryFileSystem',
2767             {
2768             'cargo' => {
2769             'type' => 'leaf',
2770             'value_type' => 'uniline'
2771             },
2772             'description' => 'Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file
2773             system namespace is set up for executed processes, and a temporary file system is mounted on each mount point.
2774             This option may be specified more than once, in which case temporary file systems are mounted on all listed mount
2775             points. If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect.
2776             Each mount point may optionally be suffixed with a colon (C<:>) and mount options such as
2777             C<size=10%> or C<ro>. By default, each temporary file system is mounted
2778             with C<nodev,strictatime,mode=0755>. These can be disabled by explicitly specifying the corresponding
2779             mount options, e.g., C<dev> or C<nostrictatime>.
2780              
2781             This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary
2782             files or directories can be still accessed by combining with C<BindPaths> or
2783             C<BindReadOnlyPaths>:
2784              
2785             Example: if a unit has the following,
2786              
2787             TemporaryFileSystem=/var:ro
2788             BindReadOnlyPaths=/var/lib/systemd
2789              
2790             then the invoked processes by the unit cannot see any files or directories under C</var/> except for
2791             C</var/lib/systemd> or its contents.',
2792             'type' => 'list'
2793             },
2794             'PrivateTmp',
2795             {
2796             'description' => 'Takes a boolean argument. If true, sets up a new file system namespace for the
2797             executed processes and mounts private C</tmp/> and C</var/tmp/>
2798             directories inside it that are not shared by processes outside of the namespace. This is useful to
2799             secure access to temporary files of the process, but makes sharing between processes via
2800             C</tmp/> or C</var/tmp/> impossible. If true, all temporary files
2801             created by a service in these directories will be removed after the service is stopped. Defaults to
2802             false. It is possible to run two or more units within the same private C</tmp/> and
2803             C</var/tmp/> namespace by using the C<JoinsNamespaceOf> directive,
2804             see L<systemd.unit(5)>
2805             for details. This setting is implied if C<DynamicUser> is set. For this setting the
2806             same restrictions regarding mount propagation and privileges apply as for
2807             C<ReadOnlyPaths> and related calls, see above. Enabling this setting has the side
2808             effect of adding C<Requires> and C<After> dependencies on all mount
2809             units necessary to access C</tmp/> and C</var/tmp/>. Moreover an
2810             implicitly C<After> ordering on
2811             L<systemd-tmpfiles-setup.service(8)>
2812             is added.
2813              
2814             Note that the implementation of this setting might be impossible (for example if mount namespaces are not
2815             available), and the unit should be written in a way that does not solely rely on this setting for
2816             security.',
2817             'type' => 'leaf',
2818             'value_type' => 'boolean',
2819             'write_as' => [
2820             'no',
2821             'yes'
2822             ]
2823             },
2824             'PrivateDevices',
2825             {
2826             'description' => 'Takes a boolean argument. If true, sets up a new C</dev/> mount for
2827             the executed processes and only adds API pseudo devices such as C</dev/null>,
2828             C</dev/zero> or C</dev/random> (as well as the pseudo TTY
2829             subsystem) to it, but no physical devices such as C</dev/sda>, system memory
2830             C</dev/mem>, system ports C</dev/port> and others. This is useful
2831             to turn off physical device access by the executed process. Defaults to false.
2832              
2833             Enabling this option will install a system call filter to block low-level I/O system calls that
2834             are grouped in the C<@raw-io> set, remove C<CAP_MKNOD> and
2835             C<CAP_SYS_RAWIO> from the capability bounding set for the unit, and set
2836             C<DevicePolicy=closed> (see
2837             L<systemd.resource-control(5)>
2838             for details). Note that using this setting will disconnect propagation of mounts from the service to
2839             the host (propagation in the opposite direction continues to work). This means that this setting may
2840             not be used for services which shall be able to install mount points in the main mount namespace. The
2841             new C</dev/> will be mounted read-only and \'noexec\'. The latter may break old
2842             programs which try to set up executable memory by using
2843             L<mmap(2)> of
2844             C</dev/zero> instead of using C<MAP_ANON>. For this setting the
2845             same restrictions regarding mount propagation and privileges apply as for
2846             C<ReadOnlyPaths> and related calls, see above. If turned on and if running in user
2847             mode, or in system mode, but without the C<CAP_SYS_ADMIN> capability (e.g. setting
2848             C<User>), C<NoNewPrivileges=yes> is implied.
2849              
2850             Note that the implementation of this setting might be impossible (for example if mount
2851             namespaces are not available), and the unit should be written in a way that does not solely rely on
2852             this setting for security.
2853              
2854             When access to some but not all devices must be possible, the C<DeviceAllow>
2855             setting might be used instead. See
2856             L<systemd.resource-control(5)>.
2857             ',
2858             'type' => 'leaf',
2859             'value_type' => 'boolean',
2860             'write_as' => [
2861             'no',
2862             'yes'
2863             ]
2864             },
2865             'PrivateNetwork',
2866             {
2867             'description' => 'Takes a boolean argument. If true, sets up a new network namespace for the executed processes
2868             and configures only the loopback network device C<lo> inside it. No other network devices will
2869             be available to the executed process. This is useful to turn off network access by the executed process.
2870             Defaults to false. It is possible to run two or more units within the same private network namespace by using
2871             the C<JoinsNamespaceOf> directive, see
2872             L<systemd.unit(5)> for
2873             details. Note that this option will disconnect all socket families from the host, including
2874             C<AF_NETLINK> and C<AF_UNIX>. Effectively, for
2875             C<AF_NETLINK> this means that device configuration events received from
2876             L<systemd-udevd.service(8)> are
2877             not delivered to the unit\'s processes. And for C<AF_UNIX> this has the effect that
2878             C<AF_UNIX> sockets in the abstract socket namespace of the host will become unavailable to
2879             the unit\'s processes (however, those located in the file system will continue to be accessible).
2880              
2881             Note that the implementation of this setting might be impossible (for example if network namespaces are
2882             not available), and the unit should be written in a way that does not solely rely on this setting for
2883             security.
2884              
2885             When this option is used on a socket unit any sockets bound on behalf of this unit will be
2886             bound within a private network namespace. This may be combined with
2887             C<JoinsNamespaceOf> to listen on sockets inside of network namespaces of other
2888             services.',
2889             'type' => 'leaf',
2890             'value_type' => 'boolean',
2891             'write_as' => [
2892             'no',
2893             'yes'
2894             ]
2895             },
2896             'NetworkNamespacePath',
2897             {
2898             'description' => 'Takes an absolute file system path refererring to a Linux network namespace
2899             pseudo-file (i.e. a file like C</proc/$PID/ns/net> or a bind mount or symlink to
2900             one). When set the invoked processes are added to the network namespace referenced by that path. The
2901             path has to point to a valid namespace file at the moment the processes are forked off. If this
2902             option is used C<PrivateNetwork> has no effect. If this option is used together with
2903             C<JoinsNamespaceOf> then it only has an effect if this unit is started before any of
2904             the listed units that have C<PrivateNetwork> or
2905             C<NetworkNamespacePath> configured, as otherwise the network namespace of those
2906             units is reused.
2907              
2908             When this option is used on a socket unit any sockets bound on behalf of this unit will be
2909             bound within the specified network namespace.',
2910             'type' => 'leaf',
2911             'value_type' => 'uniline'
2912             },
2913             'PrivateIPC',
2914             {
2915             'description' => 'Takes a boolean argument. If true, sets up a new IPC namespace for the executed processes.
2916             Each IPC namespace has its own set of System V IPC identifiers and its own POSIX message queue file system.
2917             This is useful to avoid name clash of IPC identifiers. Defaults to false. It is possible to run two or
2918             more units within the same private IPC namespace by using the C<JoinsNamespaceOf> directive,
2919             see L<systemd.unit(5)> for
2920             details.
2921              
2922             Note that IPC namespacing does not have an effect on
2923             C<AF_UNIX> sockets, which are the most common
2924             form of IPC used on Linux. Instead, C<AF_UNIX>
2925             sockets in the file system are subject to mount namespacing, and
2926             those in the abstract namespace are subject to network namespacing.
2927             IPC namespacing only has an effect on SysV IPC (which is mostly
2928             legacy) as well as POSIX message queues (for which
2929             C<AF_UNIX>/C<SOCK_SEQPACKET>
2930             sockets are typically a better replacement). IPC namespacing also
2931             has no effect on POSIX shared memory (which is subject to mount
2932             namespacing) either. See
2933             L<ipc_namespaces(7)> for
2934             the details.
2935              
2936             Note that the implementation of this setting might be impossible (for example if IPC namespaces are
2937             not available), and the unit should be written in a way that does not solely rely on this setting for
2938             security.',
2939             'type' => 'leaf',
2940             'value_type' => 'boolean',
2941             'write_as' => [
2942             'no',
2943             'yes'
2944             ]
2945             },
2946             'IPCNamespacePath',
2947             {
2948             'description' => 'Takes an absolute file system path refererring to a Linux IPC namespace
2949             pseudo-file (i.e. a file like C</proc/$PID/ns/ipc> or a bind mount or symlink to
2950             one). When set the invoked processes are added to the network namespace referenced by that path. The
2951             path has to point to a valid namespace file at the moment the processes are forked off. If this
2952             option is used C<PrivateIPC> has no effect. If this option is used together with
2953             C<JoinsNamespaceOf> then it only has an effect if this unit is started before any of
2954             the listed units that have C<PrivateIPC> or
2955             C<IPCNamespacePath> configured, as otherwise the network namespace of those
2956             units is reused.',
2957             'type' => 'leaf',
2958             'value_type' => 'uniline'
2959             },
2960             'PrivateUsers',
2961             {
2962             'description' => 'Takes a boolean argument. If true, sets up a new user namespace for the executed processes and
2963             configures a minimal user and group mapping, that maps the C<root> user and group as well as
2964             the unit\'s own user and group to themselves and everything else to the C<nobody> user and
2965             group. This is useful to securely detach the user and group databases used by the unit from the rest of the
2966             system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and
2967             other resources owned by users/groups not equaling C<root> or the unit\'s own will stay visible
2968             from within the unit but appear owned by the C<nobody> user and group. If this mode is enabled,
2969             all unit processes are run without privileges in the host user namespace (regardless if the unit\'s own
2970             user/group is C<root> or not). Specifically this means that the process will have zero process
2971             capabilities on the host\'s user namespace, but full capabilities within the service\'s user namespace. Settings
2972             such as C<CapabilityBoundingSet> will affect only the latter, and there\'s no way to acquire
2973             additional capabilities in the host\'s user namespace. Defaults to off.
2974              
2975             When this setting is set up by a per-user instance of the service manager, the mapping of the
2976             C<root> user and group to itself is omitted (unless the user manager is root).
2977             Additionally, in the per-user instance manager case, the
2978             user namespace will be set up before most other namespaces. This means that combining
2979             C<PrivateUsers>C<true> with other namespaces will enable use of features not
2980             normally supported by the per-user instances of the service manager.
2981              
2982             This setting is particularly useful in conjunction with
2983             C<RootDirectory>/C<RootImage>, as the need to synchronize the user and group
2984             databases in the root directory and on the host is reduced, as the only users and groups who need to be matched
2985             are C<root>, C<nobody> and the unit\'s own user and group.
2986              
2987             Note that the implementation of this setting might be impossible (for example if user namespaces are not
2988             available), and the unit should be written in a way that does not solely rely on this setting for
2989             security.',
2990             'type' => 'leaf',
2991             'value_type' => 'boolean',
2992             'write_as' => [
2993             'no',
2994             'yes'
2995             ]
2996             },
2997             'ProtectHostname',
2998             {
2999             'description' => 'Takes a boolean argument. When set, sets up a new UTS namespace for the executed
3000             processes. In addition, changing hostname or domainname is prevented. Defaults to off.
3001              
3002             Note that the implementation of this setting might be impossible (for example if UTS namespaces
3003             are not available), and the unit should be written in a way that does not solely rely on this setting
3004             for security.
3005              
3006             Note that when this option is enabled for a service hostname changes no longer propagate from
3007             the system into the service, it is hence not suitable for services that need to take notice of system
3008             hostname changes dynamically.
3009              
3010             If this setting is on, but the unit doesn\'t have the C<CAP_SYS_ADMIN>
3011             capability (e.g. services for which C<User> is set),
3012             C<NoNewPrivileges=yes> is implied.',
3013             'type' => 'leaf',
3014             'value_type' => 'boolean',
3015             'write_as' => [
3016             'no',
3017             'yes'
3018             ]
3019             },
3020             'ProtectClock',
3021             {
3022             'description' => 'Takes a boolean argument. If set, writes to the hardware clock or system clock will be denied.
3023             It is recommended to turn this on for most services that do not need modify the clock. Defaults to off. Enabling
3024             this option removes C<CAP_SYS_TIME> and C<CAP_WAKE_ALARM> from the
3025             capability bounding set for this unit, installs a system call filter to block calls that can set the
3026             clock, and C<DeviceAllow=char-rtc r> is implied. This ensures C</dev/rtc0>,
3027             C</dev/rtc1>, etc. are made read-only to the service. See
3028             L<systemd.resource-control(5)>
3029             for the details about C<DeviceAllow>. If this setting is on, but the unit
3030             doesn\'t have the C<CAP_SYS_ADMIN> capability (e.g. services for which
3031             C<User> is set), C<NoNewPrivileges=yes> is implied.',
3032             'type' => 'leaf',
3033             'value_type' => 'boolean',
3034             'write_as' => [
3035             'no',
3036             'yes'
3037             ]
3038             },
3039             'ProtectKernelTunables',
3040             {
3041             'description' => 'Takes a boolean argument. If true, kernel variables accessible through
3042             C</proc/sys/>, C</sys/>, C</proc/sysrq-trigger>,
3043             C</proc/latency_stats>, C</proc/acpi>,
3044             C</proc/timer_stats>, C</proc/fs> and C</proc/irq> will
3045             be made read-only to all processes of the unit. Usually, tunable kernel variables should be initialized only at
3046             boot-time, for example with the
3047             L<sysctl.d(5)> mechanism. Few
3048             services need to write to these at runtime; it is hence recommended to turn this on for most services. For this
3049             setting the same restrictions regarding mount propagation and privileges apply as for
3050             C<ReadOnlyPaths> and related calls, see above. Defaults to off. If this
3051             setting is on, but the unit doesn\'t have the C<CAP_SYS_ADMIN> capability
3052             (e.g. services for which C<User> is set),
3053             C<NoNewPrivileges=yes> is implied. Note that this option does not prevent
3054             indirect changes to kernel tunables effected by IPC calls to other processes. However,
3055             C<InaccessiblePaths> may be used to make relevant IPC file system objects
3056             inaccessible. If C<ProtectKernelTunables> is set,
3057             C<MountAPIVFS=yes> is implied.',
3058             'type' => 'leaf',
3059             'value_type' => 'boolean',
3060             'write_as' => [
3061             'no',
3062             'yes'
3063             ]
3064             },
3065             'ProtectKernelModules',
3066             {
3067             'description' => 'Takes a boolean argument. If true, explicit module loading will be denied. This allows
3068             module load and unload operations to be turned off on modular kernels. It is recommended to turn this on for most services
3069             that do not need special file systems or extra kernel modules to work. Defaults to off. Enabling this option
3070             removes C<CAP_SYS_MODULE> from the capability bounding set for the unit, and installs a
3071             system call filter to block module system calls, also C</usr/lib/modules> is made
3072             inaccessible. For this setting the same restrictions regarding mount propagation and privileges apply as for
3073             C<ReadOnlyPaths> and related calls, see above. Note that limited automatic module loading due
3074             to user configuration or kernel mapping tables might still happen as side effect of requested user operations,
3075             both privileged and unprivileged. To disable module auto-load feature please see
3076             L<sysctl.d(5)>C<kernel.modules_disabled> mechanism and
3077             C</proc/sys/kernel/modules_disabled> documentation. If this setting is on,
3078             but the unit doesn\'t have the C<CAP_SYS_ADMIN> capability (e.g. services for
3079             which C<User> is set), C<NoNewPrivileges=yes> is implied.',
3080             'type' => 'leaf',
3081             'value_type' => 'boolean',
3082             'write_as' => [
3083             'no',
3084             'yes'
3085             ]
3086             },
3087             'ProtectKernelLogs',
3088             {
3089             'description' => 'Takes a boolean argument. If true, access to the kernel log ring buffer will be denied. It is
3090             recommended to turn this on for most services that do not need to read from or write to the kernel log ring
3091             buffer. Enabling this option removes C<CAP_SYSLOG> from the capability bounding set for this
3092             unit, and installs a system call filter to block the
3093             L<syslog(2)>
3094             system call (not to be confused with the libc API
3095             L<syslog(3)>
3096             for userspace logging). The kernel exposes its log buffer to userspace via C</dev/kmsg> and
3097             C</proc/kmsg>. If enabled, these are made inaccessible to all the processes in the unit.
3098             If this setting is on, but the unit doesn\'t have the C<CAP_SYS_ADMIN>
3099             capability (e.g. services for which C<User> is set),
3100             C<NoNewPrivileges=yes> is implied.',
3101             'type' => 'leaf',
3102             'value_type' => 'boolean',
3103             'write_as' => [
3104             'no',
3105             'yes'
3106             ]
3107             },
3108             'ProtectControlGroups',
3109             {
3110             'description' => 'Takes a boolean argument. If true, the Linux Control Groups (L<cgroups(7)>) hierarchies
3111             accessible through C</sys/fs/cgroup/> will be made read-only to all processes of the
3112             unit. Except for container managers no services should require write access to the control groups hierarchies;
3113             it is hence recommended to turn this on for most services. For this setting the same restrictions regarding
3114             mount propagation and privileges apply as for C<ReadOnlyPaths> and related calls, see
3115             above. Defaults to off. If C<ProtectControlGroups> is set, C<MountAPIVFS=yes>
3116             is implied.',
3117             'type' => 'leaf',
3118             'value_type' => 'boolean',
3119             'write_as' => [
3120             'no',
3121             'yes'
3122             ]
3123             },
3124             'RestrictAddressFamilies',
3125             {
3126             'description' => 'Restricts the set of socket address families accessible to the processes of this
3127             unit. Takes C<none>, or a space-separated list of address family names to
3128             allow-list, such as C<AF_UNIX>, C<AF_INET> or
3129             C<AF_INET6>. When C<none> is specified, then all address
3130             families will be denied. When prefixed with C<~> the listed address
3131             families will be applied as deny list, otherwise as allow list. Note that this restricts access
3132             to the
3133             L<socket(2)>
3134             system call only. Sockets passed into the process by other means (for example, by using socket
3135             activation with socket units, see
3136             L<systemd.socket(5)>)
3137             are unaffected. Also, sockets created with socketpair() (which creates connected
3138             AF_UNIX sockets only) are unaffected. Note that this option has no effect on 32-bit x86, s390, s390x,
3139             mips, mips-le, ppc, ppc-le, ppc64, ppc64-le and is ignored (but works correctly on other ABIs,
3140             including x86-64). Note that on systems supporting multiple ABIs (such as x86/x86-64) it is
3141             recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the
3142             restrictions of this option. Specifically, it is recommended to combine this option with
3143             C<SystemCallArchitectures=native> or similar. If running in user mode, or in system
3144             mode, but without the C<CAP_SYS_ADMIN> capability (e.g. setting
3145             C<User>), C<NoNewPrivileges=yes> is implied. By default, no
3146             restrictions apply, all address families are accessible to processes. If assigned the empty string,
3147             any previous address family restriction changes are undone. This setting does not affect commands
3148             prefixed with C<+>.
3149              
3150             Use this option to limit exposure of processes to remote access, in particular via exotic and sensitive
3151             network protocols, such as C<AF_PACKET>. Note that in most cases, the local
3152             C<AF_UNIX> address family should be included in the configured allow list as it is frequently
3153             used for local communication, including for
3154             L<syslog(2)>
3155             logging.',
3156             'type' => 'leaf',
3157             'value_type' => 'uniline'
3158             },
3159             'RestrictFileSystems',
3160             {
3161             'description' => 'Restricts the set of filesystems processes of this unit can open files on. Takes a space-separated
3162             list of filesystem names. Any filesystem listed is made accessible to the unit\'s processes, access to filesystem
3163             types not listed is prohibited (allow-listing). If the first character of the list is C<~>, the
3164             effect is inverted: access to the filesystems listed is prohibited (deny-listing). If the empty string is assigned,
3165             access to filesystems is not restricted.
3166              
3167             If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered will take
3168             precedence and will dictate the default action (allow access to the filesystem or deny it). Then the next occurrences
3169             of this option will add or delete the listed filesystems from the set of the restricted filesystems, depending on its
3170             type and the default action.
3171              
3172             Example: if a unit has the following,
3173              
3174             RestrictFileSystems=ext4 tmpfs
3175             RestrictFileSystems=ext2 ext4
3176              
3177             then access to C<ext4>, C<tmpfs>, and C<ext2> is allowed
3178             and access to other filesystems is denied.
3179              
3180             Example: if a unit has the following,
3181              
3182             RestrictFileSystems=ext4 tmpfs
3183             RestrictFileSystems=~ext4
3184              
3185             then only access C<tmpfs> is allowed.
3186              
3187             Example: if a unit has the following,
3188              
3189             RestrictFileSystems=~ext4 tmpfs
3190             RestrictFileSystems=ext4
3191              
3192             then only access to C<tmpfs> is denied.
3193              
3194             As the number of possible filesystems is large, predefined sets of filesystems are provided. A set
3195             starts with C<@> character, followed by name of the set.
3196              
3197             Use
3198             L<systemd-analyze(1)>\'s
3199             filesystems command to retrieve a list of filesystems defined on the local
3200             system.
3201              
3202             Note that this setting might not be supported on some systems (for example if the LSM eBPF hook is
3203             not enabled in the underlying kernel or if not using the unified control group hierarchy). In that case this setting
3204             has no effect.',
3205             'type' => 'leaf',
3206             'value_type' => 'uniline'
3207             },
3208             'RestrictNamespaces',
3209             {
3210             'description' => "Restricts access to Linux namespace functionality for the processes of this unit. For details
3211             about Linux namespaces, see L<namespaces(7)>. Either
3212             takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the default), no
3213             restrictions on namespace creation and switching are made. If true, access to any kind of namespacing is
3214             prohibited. Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of
3215             any combination of: C<cgroup>, C<ipc>, C<net>,
3216             C<mnt>, C<pid>, C<user> and C<uts>. Any
3217             namespace type listed is made accessible to the unit's processes, access to namespace types not listed is
3218             prohibited (allow-listing). By prepending the list with a single tilde character (C<~>) the
3219             effect may be inverted: only the listed namespace types will be made inaccessible, all unlisted ones are
3220             permitted (deny-listing). If the empty string is assigned, the default namespace restrictions are applied,
3221             which is equivalent to false. This option may appear more than once, in which case the namespace types are
3222             merged by C<OR>, or by C<AND> if the lines are prefixed with
3223             C<~> (see examples below). Internally, this setting limits access to the
3224             L<unshare(2)>,
3225             L<clone(2)> and
3226             L<setns(2)> system calls, taking
3227             the specified flags parameters into account. Note that \x{2014} if this option is used \x{2014} in addition to restricting
3228             creation and switching of the specified types of namespaces (or all of them, if true) access to the
3229             setns() system call with a zero flags parameter is prohibited. This setting is only
3230             supported on x86, x86-64, mips, mips-le, mips64, mips64-le, mips64-n32, mips64-le-n32, ppc64, ppc64-le, s390
3231             and s390x, and enforces no restrictions on other architectures. If running in user mode, or in system mode, but
3232             without the C<CAP_SYS_ADMIN> capability (e.g. setting C<User>),
3233             C<NoNewPrivileges=yes> is implied.
3234              
3235             Example: if a unit has the following,
3236              
3237             RestrictNamespaces=cgroup ipc
3238             RestrictNamespaces=cgroup net
3239              
3240             then C<cgroup>, C<ipc>, and C<net> are set.
3241             If the second line is prefixed with C<~>, e.g.,
3242              
3243             RestrictNamespaces=cgroup ipc
3244             RestrictNamespaces=~cgroup net
3245              
3246             then, only C<ipc> is set.",
3247             'type' => 'leaf',
3248             'value_type' => 'uniline'
3249             },
3250             'LockPersonality',
3251             {
3252             'description' => 'Takes a boolean argument. If set, locks down the L<personality(2)> system
3253             call so that the kernel execution domain may not be changed from the default or the personality selected with
3254             C<Personality> directive. This may be useful to improve security, because odd personality
3255             emulations may be poorly tested and source of vulnerabilities. If running in user mode, or in system mode, but
3256             without the C<CAP_SYS_ADMIN> capability (e.g. setting C<User>),
3257             C<NoNewPrivileges=yes> is implied.',
3258             'type' => 'leaf',
3259             'value_type' => 'boolean',
3260             'write_as' => [
3261             'no',
3262             'yes'
3263             ]
3264             },
3265             'MemoryDenyWriteExecute',
3266             {
3267             'description' => 'Takes a boolean argument. If set, attempts to create memory mappings that are writable and
3268             executable at the same time, or to change existing memory mappings to become executable, or mapping shared
3269             memory segments as executable are prohibited. Specifically, a system call filter is added that rejects
3270             L<mmap(2)> system calls with both
3271             C<PROT_EXEC> and C<PROT_WRITE> set,
3272             L<mprotect(2)> or
3273             L<pkey_mprotect(2)> system calls
3274             with C<PROT_EXEC> set and
3275             L<shmat(2)> system calls with
3276             C<SHM_EXEC> set. Note that this option is incompatible with programs and libraries that
3277             generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code
3278             "trampoline" feature of various C compilers. This option improves service security, as it makes harder for
3279             software exploits to change running code dynamically. However, the protection can be circumvented, if
3280             the service can write to a filesystem, which is not mounted with C<noexec> (such as
3281             C</dev/shm>), or it can use memfd_create(). This can be
3282             prevented by making such file systems inaccessible to the service
3283             (e.g. C<InaccessiblePaths=/dev/shm>) and installing further system call filters
3284             (C<SystemCallFilter=~memfd_create>). Note that this feature is fully available on
3285             x86-64, and partially on x86. Specifically, the shmat() protection is not
3286             available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is
3287             recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the
3288             restrictions of this option. Specifically, it is recommended to combine this option with
3289             C<SystemCallArchitectures=native> or similar. If running in user mode, or in system
3290             mode, but without the C<CAP_SYS_ADMIN> capability (e.g. setting
3291             C<User>), C<NoNewPrivileges=yes> is implied.',
3292             'type' => 'leaf',
3293             'value_type' => 'boolean',
3294             'write_as' => [
3295             'no',
3296             'yes'
3297             ]
3298             },
3299             'RestrictRealtime',
3300             {
3301             'description' => 'Takes a boolean argument. If set, any attempts to enable realtime scheduling in a process of
3302             the unit are refused. This restricts access to realtime task scheduling policies such as
3303             C<SCHED_FIFO>, C<SCHED_RR> or C<SCHED_DEADLINE>. See
3304             L<sched(7)>
3305             for details about these scheduling policies. If running in user mode, or in system mode, but without the
3306             C<CAP_SYS_ADMIN> capability (e.g. setting C<User>),
3307             C<NoNewPrivileges=yes> is implied. Realtime scheduling policies may be used to monopolize CPU
3308             time for longer periods of time, and may hence be used to lock up or otherwise trigger Denial-of-Service
3309             situations on the system. It is hence recommended to restrict access to realtime scheduling to the few programs
3310             that actually require them. Defaults to off.',
3311             'type' => 'leaf',
3312             'value_type' => 'boolean',
3313             'write_as' => [
3314             'no',
3315             'yes'
3316             ]
3317             },
3318             'RestrictSUIDSGID',
3319             {
3320             'description' => 'Takes a boolean argument. If set, any attempts to set the set-user-ID (SUID) or
3321             set-group-ID (SGID) bits on files or directories will be denied (for details on these bits see
3322             L<inode(7)>). If
3323             running in user mode, or in system mode, but without the C<CAP_SYS_ADMIN>
3324             capability (e.g. setting C<User>), C<NoNewPrivileges=yes> is
3325             implied. As the SUID/SGID bits are mechanisms to elevate privileges, and allows users to acquire the
3326             identity of other users, it is recommended to restrict creation of SUID/SGID files to the few
3327             programs that actually require them. Note that this restricts marking of any type of file system
3328             object with these bits, including both regular files and directories (where the SGID is a different
3329             meaning than for files, see documentation). This option is implied if C<DynamicUser>
3330             is enabled. Defaults to off.',
3331             'type' => 'leaf',
3332             'value_type' => 'boolean',
3333             'write_as' => [
3334             'no',
3335             'yes'
3336             ]
3337             },
3338             'RemoveIPC',
3339             {
3340             'description' => 'Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and
3341             group the processes of this unit are run as are removed when the unit is stopped. This setting only has an
3342             effect if at least one of C<User>, C<Group> and
3343             C<DynamicUser> are used. It has no effect on IPC objects owned by the root user. Specifically,
3344             this removes System V semaphores, as well as System V and POSIX shared memory segments and message queues. If
3345             multiple units use the same user or group the IPC objects are removed when the last of these units is
3346             stopped. This setting is implied if C<DynamicUser> is set.',
3347             'type' => 'leaf',
3348             'value_type' => 'boolean',
3349             'write_as' => [
3350             'no',
3351             'yes'
3352             ]
3353             },
3354             'PrivateMounts',
3355             {
3356             'description' => "Takes a boolean parameter. If set, the processes of this unit will be run in their own private
3357             file system (mount) namespace with all mount propagation from the processes towards the host's main file system
3358             namespace turned off. This means any file system mount points established or removed by the unit's processes
3359             will be private to them and not be visible to the host. However, file system mount points established or
3360             removed on the host will be propagated to the unit's processes. See L<mount_namespaces(7)> for
3361             details on file system namespaces. Defaults to off.
3362              
3363             When turned on, this executes three operations for each invoked process: a new
3364             C<CLONE_NEWNS> namespace is created, after which all existing mounts are remounted to
3365             C<MS_SLAVE> to disable propagation from the unit's processes to the host (but leaving
3366             propagation in the opposite direction in effect). Finally, the mounts are remounted again to the propagation
3367             mode configured with C<MountFlags>, see below.
3368              
3369             File system namespaces are set up individually for each process forked off by the service manager. Mounts
3370             established in the namespace of the process created by C<ExecStartPre> will hence be cleaned
3371             up automatically as soon as that process exits and will not be available to subsequent processes forked off for
3372             C<ExecStart> (and similar applies to the various other commands configured for
3373             units). Similarly, C<JoinsNamespaceOf> does not permit sharing kernel mount namespaces between
3374             units, it only enables sharing of the C</tmp/> and C</var/tmp/>
3375             directories.
3376              
3377             Other file system namespace unit settings \x{2014} C<PrivateMounts>,
3378             C<PrivateTmp>, C<PrivateDevices>, C<ProtectSystem>,
3379             C<ProtectHome>, C<ReadOnlyPaths>, C<InaccessiblePaths>,
3380             C<ReadWritePaths>, \x{2026} \x{2014} also enable file system namespacing in a fashion equivalent to this
3381             option. Hence it is primarily useful to explicitly request this behaviour if none of the other settings are
3382             used.",
3383             'type' => 'leaf',
3384             'value_type' => 'boolean',
3385             'write_as' => [
3386             'no',
3387             'yes'
3388             ]
3389             },
3390             'MountFlags',
3391             {
3392             'description' => "Takes a mount propagation setting: C<shared>, C<slave> or
3393             C<private>, which controls whether file system mount points in the file system namespaces set up
3394             for this unit's processes will receive or propagate mounts and unmounts from other file system namespaces. See
3395             L<mount(2)>
3396             for details on mount propagation, and the three propagation flags in particular.
3397              
3398             This setting only controls the final propagation setting in effect on all mount
3399             points of the file system namespace created for each process of this unit. Other file system namespacing unit
3400             settings (see the discussion in C<PrivateMounts> above) will implicitly disable mount and
3401             unmount propagation from the unit's processes towards the host by changing the propagation setting of all mount
3402             points in the unit's file system namespace to C<slave> first. Setting this option to
3403             C<shared> does not reestablish propagation in that case.
3404              
3405             If not set \x{2013} but file system namespaces are enabled through another file system namespace unit setting \x{2013}
3406             C<shared> mount propagation is used, but \x{2014} as mentioned \x{2014} as C<slave> is applied
3407             first, propagation from the unit's processes to the host is still turned off.
3408              
3409             It is not recommended to use C<private> mount propagation for units, as this means
3410             temporary mounts (such as removable media) of the host will stay mounted and thus indefinitely busy in forked
3411             off processes, as unmount propagation events won't be received by the file system namespace of the unit.
3412              
3413             Usually, it is best to leave this setting unmodified, and use higher level file system namespacing
3414             options instead, in particular C<PrivateMounts>, see above.",
3415             'type' => 'leaf',
3416             'value_type' => 'uniline'
3417             },
3418             'SystemCallFilter',
3419             {
3420             'cargo' => {
3421             'type' => 'leaf',
3422             'value_type' => 'uniline'
3423             },
3424             'description' => "Takes a space-separated list of system call names. If this setting is used, all
3425             system calls executed by the unit processes except for the listed ones will result in immediate
3426             process termination with the C<SIGSYS> signal (allow-listing). (See
3427             C<SystemCallErrorNumber> below for changing the default action). If the first
3428             character of the list is C<~>, the effect is inverted: only the listed system calls
3429             will result in immediate process termination (deny-listing). Deny-listed system calls and system call
3430             groups may optionally be suffixed with a colon (C<:>) and C<errno>
3431             error number (between 0 and 4095) or errno name such as C<EPERM>,
3432             C<EACCES> or C<EUCLEAN> (see L<errno(3)> for a
3433             full list). This value will be returned when a deny-listed system call is triggered, instead of
3434             terminating the processes immediately. Special setting C<kill> can be used to
3435             explicitly specify killing. This value takes precedence over the one given in
3436             C<SystemCallErrorNumber>, see below. If running in user mode, or in system mode,
3437             but without the C<CAP_SYS_ADMIN> capability (e.g. setting
3438             C<User>), C<NoNewPrivileges=yes> is implied. This feature
3439             makes use of the Secure Computing Mode 2 interfaces of the kernel ('seccomp filtering') and is useful
3440             for enforcing a minimal sandboxing environment. Note that the execve(),
3441             exit(), exit_group(), getrlimit(),
3442             rt_sigreturn(), sigreturn() system calls and the system calls
3443             for querying time and sleeping are implicitly allow-listed and do not need to be listed
3444             explicitly. This option may be specified more than once, in which case the filter masks are
3445             merged. If the empty string is assigned, the filter is reset, all prior assignments will have no
3446             effect. This does not affect commands prefixed with C<+>.
3447              
3448             Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off
3449             alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this
3450             option. Specifically, it is recommended to combine this option with
3451             C<SystemCallArchitectures=native> or similar.
3452              
3453             Note that strict system call filters may impact execution and error handling code paths of the service
3454             invocation. Specifically, access to the execve() system call is required for the execution
3455             of the service binary \x{2014} if it is blocked service invocation will necessarily fail. Also, if execution of the
3456             service binary fails for some reason (for example: missing service executable), the error handling logic might
3457             require access to an additional set of system calls in order to process and log this failure correctly. It
3458             might be necessary to temporarily disable system call filters in order to simplify debugging of such
3459             failures.
3460              
3461             If you specify both types of this option (i.e. allow-listing and deny-listing), the first
3462             encountered will take precedence and will dictate the default action (termination or approval of a
3463             system call). Then the next occurrences of this option will add or delete the listed system calls
3464             from the set of the filtered system calls, depending of its type and the default action. (For
3465             example, if you have started with an allow list rule for read() and
3466             write(), and right after it add a deny list rule for write(),
3467             then write() will be removed from the set.)
3468              
3469             As the number of possible system calls is large, predefined sets of system calls are provided. A set
3470             starts with C<\@> character, followed by name of the set.
3471             Currently predefined system call setsSetDescription\@aioAsynchronous I/O (L<io_setup(2)>, L<io_submit(2)>, and related calls)\@basic-ioSystem calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing (L<read(2)>, L<write(2)>, and related calls)\@chownChanging file ownership (L<chown(2)>, L<fchownat(2)>, and related calls)\@clockSystem calls for changing the system clock (L<adjtimex(2)>, L<settimeofday(2)>, and related calls)\@cpu-emulationSystem calls for CPU emulation functionality (L<vm86(2)> and related calls)\@debugDebugging, performance monitoring and tracing functionality (L<ptrace(2)>, L<perf_event_open(2)> and related calls)\@file-systemFile 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-eventEvent loop system calls (L<poll(2)>, L<select(2)>, L<epoll(7)>, L<eventfd(2)> and related calls)\@ipcPipes, SysV IPC, POSIX Message Queues and other IPC (L<mq_overview(7)>, L<svipc(7)>)\@keyringKernel keyring access (L<keyctl(2)> and related calls)\@memlockLocking of memory in RAM (L<mlock(2)>, L<mlockall(2)> and related calls)\@moduleLoading and unloading of kernel modules (L<init_module(2)>, L<delete_module(2)> and related calls)\@mountMounting and unmounting of file systems (L<mount(2)>, L<chroot(2)>, and related calls)\@network-ioSocket I/O (including local AF_UNIX): L<socket(7)>, L<unix(7)>\@obsoleteUnusual, obsolete or unimplemented (L<create_module(2)>, L<gtty(2)>, \x{2026})\@privilegedAll system calls which need super-user capabilities (L<capabilities(7)>)\@processProcess control, execution, namespacing operations (L<clone(2)>, L<kill(2)>, L<namespaces(7)>, \x{2026})\@raw-ioRaw I/O port access (L<ioperm(2)>, L<iopl(2)>, pciconfig_read(), \x{2026})\@rebootSystem calls for rebooting and reboot preparation (L<reboot(2)>, kexec(), \x{2026})\@resourcesSystem calls for changing resource limits, memory and scheduling parameters (L<setrlimit(2)>, L<setpriority(2)>, \x{2026})\@setuidSystem calls for changing user ID and group ID credentials, (L<setuid(2)>, L<setgid(2)>, L<setresuid(2)>, \x{2026})\@signalSystem calls for manipulating and handling process signals (L<signal(2)>, L<sigprocmask(2)>, \x{2026})\@swapSystem calls for enabling/disabling swap devices (L<swapon(2)>, L<swapoff(2)>)\@syncSynchronizing files and memory to disk (L<fsync(2)>, L<msync(2)>, and related calls)\@system-serviceA 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: C<\@clock>, C<\@mount>, C<\@swap>, C<\@reboot>.\@timerSystem calls for scheduling operations by time (L<alarm(2)>, L<timer_create(2)>, \x{2026})\@knownAll 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.
3472             Note, that as new system calls are added to the kernel, additional system calls might be added to the groups
3473             above. Contents of the sets may also change between systemd versions. In addition, the list of system calls
3474             depends on the kernel version and architecture for which systemd was compiled. Use
3475             systemd-analyze\x{a0}syscall-filter to list the actual list of system calls in each
3476             filter.
3477              
3478             Generally, allow-listing system calls (rather than deny-listing) is the safer mode of
3479             operation. It is recommended to enforce system call allow lists for all long-running system
3480             services. Specifically, the following lines are a relatively safe basic choice for the majority of
3481             system services:
3482              
3483             Note that various kernel system calls are defined redundantly: there are multiple system calls
3484             for executing the same operation. For example, the pidfd_send_signal() system
3485             call may be used to execute operations similar to what can be done with the older
3486             kill() system call, hence blocking the latter without the former only provides
3487             weak protection. Since new system calls are added regularly to the kernel as development progresses,
3488             keeping system call deny lists comprehensive requires constant work. It is thus recommended to use
3489             allow-listing instead, which offers the benefit that new system calls are by default implicitly
3490             blocked until the allow list is updated.
3491              
3492             Also note that a number of system calls are required to be accessible for the dynamic linker to
3493             work. The dynamic linker is required for running most regular programs (specifically: all dynamic ELF
3494             binaries, which is how most distributions build packaged programs). This means that blocking these
3495             system calls (which include open(), openat() or
3496             mmap()) will make most programs typically shipped with generic distributions
3497             unusable.
3498              
3499             It is recommended to combine the file system namespacing related options with
3500             C<SystemCallFilter=~\@mount>, in order to prohibit the unit's processes to undo the
3501             mappings. Specifically these are the options C<PrivateTmp>,
3502             C<PrivateDevices>, C<ProtectSystem>, C<ProtectHome>,
3503             C<ProtectKernelTunables>, C<ProtectControlGroups>,
3504             C<ProtectKernelLogs>, C<ProtectClock>, C<ReadOnlyPaths>,
3505             C<InaccessiblePaths> and C<ReadWritePaths>.",
3506             'type' => 'list'
3507             },
3508             'SystemCallErrorNumber',
3509             {
3510             'description' => 'Takes an C<errno> error number (between 1 and 4095) or errno name
3511             such as C<EPERM>, C<EACCES> or C<EUCLEAN>, to
3512             return when the system call filter configured with C<SystemCallFilter> is triggered,
3513             instead of terminating the process immediately. See L<errno(3)> for a
3514             full list of error codes. When this setting is not used, or when the empty string or the special
3515             setting C<kill> is assigned, the process will be terminated immediately when the
3516             filter is triggered.',
3517             'type' => 'leaf',
3518             'value_type' => 'uniline'
3519             },
3520             'SystemCallArchitectures',
3521             {
3522             'description' => "Takes a space-separated list of architecture identifiers to include in the system call
3523             filter. The known architecture identifiers are the same as for C<ConditionArchitecture>
3524             described in L<systemd.unit(5)>,
3525             as well as C<x32>, C<mips64-n32>, C<mips64-le-n32>, and
3526             the special identifier C<native>. The special identifier C<native>
3527             implicitly maps to the native architecture of the system (or more precisely: to the architecture the system
3528             manager is compiled for). If running in user mode, or in system mode, but without the
3529             C<CAP_SYS_ADMIN> capability (e.g. setting C<User>),
3530             C<NoNewPrivileges=yes> is implied. By default, this option is set to the empty list, i.e. no
3531             filtering is applied.
3532              
3533             If this setting is used, processes of this unit will only be permitted to call native system calls, and
3534             system calls of the specified architectures. For the purposes of this option, the x32 architecture is treated
3535             as including x86-64 system calls. However, this setting still fulfills its purpose, as explained below, on
3536             x32.
3537              
3538             System call filtering is not equally effective on all architectures. For example, on x86
3539             filtering of network socket-related calls is not possible, due to ABI limitations \x{2014} a limitation that x86-64
3540             does not have, however. On systems supporting multiple ABIs at the same time \x{2014} such as x86/x86-64 \x{2014} it is hence
3541             recommended to limit the set of permitted system call architectures so that secondary ABIs may not be used to
3542             circumvent the restrictions applied to the native ABI of the system. In particular, setting
3543             C<SystemCallArchitectures=native> is a good choice for disabling non-native ABIs.
3544              
3545             System call architectures may also be restricted system-wide via the
3546             C<SystemCallArchitectures> option in the global configuration. See
3547             L<systemd-system.conf(5)> for
3548             details.",
3549             'type' => 'leaf',
3550             'value_type' => 'uniline'
3551             },
3552             'SystemCallLog',
3553             {
3554             'cargo' => {
3555             'type' => 'leaf',
3556             'value_type' => 'uniline'
3557             },
3558             'description' => 'Takes a space-separated list of system call names. If this setting is used, all
3559             system calls executed by the unit processes for the listed ones will be logged. If the first
3560             character of the list is C<~>, the effect is inverted: all system calls except the
3561             listed system calls will be logged. If running in user mode, or in system mode, but without the
3562             C<CAP_SYS_ADMIN> capability (e.g. setting C<User>),
3563             C<NoNewPrivileges=yes> is implied. This feature makes use of the Secure Computing
3564             Mode 2 interfaces of the kernel (\'seccomp filtering\') and is useful for auditing or setting up a
3565             minimal sandboxing environment. This option may be specified more than once, in which case the filter
3566             masks are merged. If the empty string is assigned, the filter is reset, all prior assignments will
3567             have no effect. This does not affect commands prefixed with C<+>.',
3568             'type' => 'list'
3569             },
3570             'Environment',
3571             {
3572             'cargo' => {
3573             'type' => 'leaf',
3574             'value_type' => 'uniline'
3575             },
3576             'description' => "Sets environment variables for executed processes. Each line is unquoted using the
3577             rules described in \"Quoting\" section in
3578             L<systemd.syntax(7)>
3579             and becomes a list of variable assignments. If you need to assign a value containing spaces or the
3580             equals sign to a variable, put quotes around the whole assignment. Variable expansion is not
3581             performed inside the strings and the C<\$> character has no special meaning. Specifier
3582             expansion is performed, see the \"Specifiers\" section in
3583             L<systemd.unit(5)>.
3584              
3585             This option may be specified more than once, in which case all listed variables will be set. If
3586             the same variable is listed twice, the later setting will override the earlier setting. If the empty
3587             string is assigned to this option, the list of environment variables is reset, all prior assignments
3588             have no effect.
3589              
3590             The names of the variables can contain ASCII letters, digits, and the underscore character.
3591             Variable names cannot be empty or start with a digit. In variable values, most characters are
3592             allowed, but non-printable characters are currently rejected.
3593              
3594             Example:
3595              
3596             Environment=\"VAR1=word1 word2\" VAR2=word3 \"VAR3=\$word 5 6\"
3597              
3598             gives three variables C<VAR1>,
3599             C<VAR2>, C<VAR3>
3600             with the values C<word1 word2>,
3601             C<word3>, C<\$word 5 6>.
3602              
3603             See L<environ(7)> for
3604             details about environment variables.
3605              
3606             Note that environment variables are not suitable for passing secrets (such as passwords, key
3607             material, \x{2026}) to service processes. Environment variables set for a unit are exposed to unprivileged
3608             clients via D-Bus IPC, and generally not understood as being data that requires protection. Moreover,
3609             environment variables are propagated down the process tree, including across security boundaries
3610             (such as setuid/setgid executables), and hence might leak to processes that should not have access to
3611             the secret data. Use C<LoadCredential>, C<LoadCredentialEncrypted>
3612             or C<SetCredentialEncrypted> (see below) to pass data to unit processes
3613             securely.",
3614             'type' => 'list'
3615             },
3616             'EnvironmentFile',
3617             {
3618             'cargo' => {
3619             'type' => 'leaf',
3620             'value_type' => 'uniline'
3621             },
3622             'description' => 'Similar to C<Environment> but reads the environment variables from a text file.
3623             The text file should contain newline-separated variable assignments. Empty lines, lines without an
3624             C<=> separator, or lines starting with C<;> or C<#> will be
3625             ignored, which may be used for commenting. The file must be UTF-8 encoded. Valid characters are L<unicode scalar values|https://www.unicode.org/glossary/#unicode_scalar_value> other than L<noncharacters|https://www.unicode.org/glossary/#noncharacter>, U+0000 NUL, and U+FEFF L<byte order mark|https://www.unicode.org/glossary/#byte_order_mark>. Control codes other than NUL
3626             are allowed.
3627              
3628             In the file, an unquoted value after the C<=> is parsed with the same backslash-escape
3629             rules as L<unquoted
3630             text|https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01> in a POSIX shell, but unlike in a shell, interior whitespace is preserved and quotes after the
3631             first non-whitespace character are preserved. Leading and trailing whitespace (space, tab, carriage return) is
3632             discarded, but interior whitespace within the line is preserved verbatim. A line ending with a backslash will be
3633             continued to the following one, with the newline itself discarded. A backslash
3634             C<\\> followed by any character other than newline will preserve the following character, so that
3635             C<\\\\> will become the value C<\\>.
3636              
3637             In the file, a C<\'>-quoted value after the C<=> can span multiple lines
3638             and contain any character verbatim other than single quote, like L<single-quoted
3639             text|https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_02> in a POSIX shell. No backslash-escape sequences are recognized. Leading and trailing whitespace
3640             outside of the single quotes is discarded.
3641              
3642             In the file, a C<">-quoted value after the C<=> can span multiple lines,
3643             and the same escape sequences are recognized as in L<double-quoted
3644             text|https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03> of a POSIX shell. Backslash (C<\\>) followed by any of C<"\\`$> will
3645             preserve that character. A backslash followed by newline is a line continuation, and the newline itself is
3646             discarded. A backslash followed by any other character is ignored; both the backslash and the following
3647             character are preserved verbatim. Leading and trailing whitespace outside of the double quotes is
3648             discarded.
3649              
3650             The argument passed should be an absolute filename or wildcard expression, optionally prefixed with
3651             C<->, which indicates that if the file does not exist, it will not be read and no error or
3652             warning message is logged. This option may be specified more than once in which case all specified files are
3653             read. If the empty string is assigned to this option, the list of file to read is reset, all prior assignments
3654             have no effect.
3655              
3656             The files listed with this directive will be read shortly before the process is executed (more
3657             specifically, after all processes from a previous unit state terminated. This means you can generate these
3658             files in one unit state, and read it with this option in the next. The files are read from the file
3659             system of the service manager, before any file system changes like bind mounts take place).
3660              
3661             Settings from these files override settings made with C<Environment>. If the same
3662             variable is set twice from these files, the files will be read in the order they are specified and the later
3663             setting will override the earlier setting.',
3664             'type' => 'list'
3665             },
3666             'PassEnvironment',
3667             {
3668             'cargo' => {
3669             'type' => 'leaf',
3670             'value_type' => 'uniline'
3671             },
3672             'description' => 'Pass environment variables set for the system service manager to executed processes. Takes a
3673             space-separated list of variable names. This option may be specified more than once, in which case all listed
3674             variables will be passed. If the empty string is assigned to this option, the list of environment variables to
3675             pass is reset, all prior assignments have no effect. Variables specified that are not set for the system
3676             manager will not be passed and will be silently ignored. Note that this option is only relevant for the system
3677             service manager, as system services by default do not automatically inherit any environment variables set for
3678             the service manager itself. However, in case of the user service manager all environment variables are passed
3679             to the executed processes anyway, hence this option is without effect for the user service manager.
3680              
3681             Variables set for invoked processes due to this setting are subject to being overridden by those
3682             configured with C<Environment> or C<EnvironmentFile>.
3683              
3684             Example:
3685              
3686             PassEnvironment=VAR1 VAR2 VAR3
3687              
3688             passes three variables C<VAR1>,
3689             C<VAR2>, C<VAR3>
3690             with the values set for those variables in PID1.
3691              
3692             See L<environ(7)> for details
3693             about environment variables.',
3694             'type' => 'list'
3695             },
3696             'UnsetEnvironment',
3697             {
3698             'cargo' => {
3699             'type' => 'leaf',
3700             'value_type' => 'uniline'
3701             },
3702             'description' => 'Explicitly unset environment variable assignments that would normally be passed from the
3703             service manager to invoked processes of this unit. Takes a space-separated list of variable names or variable
3704             assignments. This option may be specified more than once, in which case all listed variables/assignments will
3705             be unset. If the empty string is assigned to this option, the list of environment variables/assignments to
3706             unset is reset. If a variable assignment is specified (that is: a variable name, followed by
3707             C<=>, followed by its value), then any environment variable matching this precise assignment is
3708             removed. If a variable name is specified (that is a variable name without any following C<=> or
3709             value), then any assignment matching the variable name, regardless of its value is removed. Note that the
3710             effect of C<UnsetEnvironment> is applied as final step when the environment list passed to
3711             executed processes is compiled. That means it may undo assignments from any configuration source, including
3712             assignments made through C<Environment> or C<EnvironmentFile>, inherited from
3713             the system manager\'s global set of environment variables, inherited via C<PassEnvironment>,
3714             set by the service manager itself (such as C<$NOTIFY_SOCKET> and such), or set by a PAM module
3715             (in case C<PAMName> is used).
3716              
3717             See "Environment Variables in Spawned Processes" below for a description of how those
3718             settings combine to form the inherited environment. See L<environ(7)> for general
3719             information about environment variables.',
3720             'type' => 'list'
3721             },
3722             'StandardInput',
3723             {
3724             'choice' => [
3725             'null',
3726             'tty',
3727             'tty-force',
3728             'tty-fail',
3729             'data',
3730             'socket'
3731             ],
3732             'description' => "Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one
3733             of C<null>, C<tty>, C<tty-force>, C<tty-fail>,
3734             C<data>, C<file:path>, C<socket> or
3735             C<fd:name>.
3736              
3737             If C<null> is selected, standard input will be connected to C</dev/null>,
3738             i.e. all read attempts by the process will result in immediate EOF.
3739              
3740             If C<tty> is selected, standard input is connected to a TTY (as configured by
3741             C<TTYPath>, see below) and the executed process becomes the controlling process of the
3742             terminal. If the terminal is already being controlled by another process, the executed process waits until the
3743             current controlling process releases the terminal.
3744              
3745             C<tty-force> is similar to C<tty>, but the executed process is forcefully and
3746             immediately made the controlling process of the terminal, potentially removing previous controlling processes
3747             from the terminal.
3748              
3749             C<tty-fail> is similar to C<tty>, but if the terminal already has a
3750             controlling process start-up of the executed process fails.
3751              
3752             The C<data> option may be used to configure arbitrary textual or binary data to pass via
3753             standard input to the executed process. The data to pass is configured via
3754             C<StandardInputText>/C<StandardInputData> (see below). Note that the actual
3755             file descriptor type passed (memory file, regular file, UNIX pipe, \x{2026}) might depend on the kernel and available
3756             privileges. In any case, the file descriptor is read-only, and when read returns the specified data followed by
3757             EOF.
3758              
3759             The C<file:path> option may be used to connect a specific file
3760             system object to standard input. An absolute path following the C<:> character is expected,
3761             which may refer to a regular file, a FIFO or special file. If an C<AF_UNIX> socket in the
3762             file system is specified, a stream socket is connected to it. The latter is useful for connecting standard
3763             input of processes to arbitrary system services.
3764              
3765             The C<socket> option is valid in socket-activated services only, and requires the relevant
3766             socket unit file (see
3767             L<systemd.socket(5)> for details)
3768             to have C<Accept=yes> set, or to specify a single socket only. If this option is set, standard
3769             input will be connected to the socket the service was activated from, which is primarily useful for
3770             compatibility with daemons designed for use with the traditional L<inetd(8)> socket activation
3771             daemon.
3772              
3773             The C<fd:name> option connects standard input to a specific,
3774             named file descriptor provided by a socket unit. The name may be specified as part of this option, following a
3775             C<:> character (e.g. C<fd:foobar>). If no name is specified, the name
3776             C<stdin> is implied (i.e. C<fd> is equivalent to C<fd:stdin>).
3777             At least one socket unit defining the specified name must be provided via the C<Sockets>
3778             option, and the file descriptor name may differ from the name of its containing socket unit. If multiple
3779             matches are found, the first one will be used. See C<FileDescriptorName> in
3780             L<systemd.socket(5)> for more
3781             details about named file descriptors and their ordering.
3782              
3783             This setting defaults to C<null>, unless
3784             C<StandardInputText>/C<StandardInputData> are set, in which case it
3785             defaults to C<data>.",
3786             'type' => 'leaf',
3787             'value_type' => 'enum'
3788             },
3789             'StandardOutput',
3790             {
3791             'choice' => [
3792             'inherit',
3793             'null',
3794             'tty',
3795             'journal',
3796             'kmsg',
3797             'journal+console',
3798             'kmsg+console',
3799             'socket'
3800             ],
3801             'description' => "Controls where file descriptor 1 (stdout) of the executed processes is connected
3802             to. Takes one of C<inherit>, C<null>, C<tty>,
3803             C<journal>, C<kmsg>, C<journal+console>,
3804             C<kmsg+console>, C<file:path>,
3805             C<append:path>, C<truncate:path>,
3806             C<socket> or C<fd:name>.
3807              
3808             C<inherit> duplicates the file descriptor of standard input for standard output.
3809              
3810             C<null> connects standard output to C</dev/null>, i.e. everything written
3811             to it will be lost.
3812              
3813             C<tty> connects standard output to a tty (as configured via C<TTYPath>,
3814             see below). If the TTY is used for output only, the executed process will not become the controlling process of
3815             the terminal, and will not fail or wait for other processes to release the terminal.
3816              
3817             C<journal> connects standard output with the journal, which is accessible via
3818             L<journalctl(1)>. Note
3819             that everything that is written to kmsg (see below) is implicitly stored in the journal as well, the
3820             specific option listed below is hence a superset of this one. (Also note that any external,
3821             additional syslog daemons receive their log data from the journal, too, hence this is the option to
3822             use when logging shall be processed with such a daemon.)
3823              
3824             C<kmsg> connects standard output with the kernel log buffer which is accessible via
3825             L<dmesg(1)>,
3826             in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which
3827             case this option is no different from C<journal>.
3828              
3829             C<journal+console> and C<kmsg+console> work in a similar way as the
3830             two options above but copy the output to the system console as well.
3831              
3832             The C<file:path> option may be used to connect a specific file
3833             system object to standard output. The semantics are similar to the same option of
3834             C<StandardInput>, see above. If path refers to a regular file
3835             on the filesystem, it is opened (created if it doesn't exist yet) for writing at the beginning of the file,
3836             but without truncating it.
3837             If standard input and output are directed to the same file path, it is opened only once \x{2014} for reading as well
3838             as writing \x{2014} and duplicated. This is particularly useful when the specified path refers to an
3839             C<AF_UNIX> socket in the file system, as in that case only a
3840             single stream connection is created for both input and output.
3841              
3842             C<append:path> is similar to
3843             C<file:path> above, but it opens the file in append mode.
3844              
3845             C<truncate:path> is similar to
3846             C<file:path> above, but it truncates the file when opening
3847             it. For units with multiple command lines, e.g. C<Type=oneshot> services with
3848             multiple C<ExecStart>, or services with C<ExecCondition>,
3849             C<ExecStartPre> or C<ExecStartPost>, the output file is reopened
3850             and therefore re-truncated for each command line. If the output file is truncated while another
3851             process still has the file open, e.g. by an C<ExecReload> running concurrently with
3852             an C<ExecStart>, and the other process continues writing to the file without
3853             adjusting its offset, then the space between the file pointers of the two processes may be filled
3854             with C<NUL> bytes, producing a sparse file. Thus,
3855             C<truncate:path> is typically only useful for units where
3856             only one process runs at a time, such as services with a single C<ExecStart> and no
3857             C<ExecStartPost>, C<ExecReload>, C<ExecStop> or
3858             similar.
3859              
3860             C<socket> connects standard output to a socket acquired via socket activation. The
3861             semantics are similar to the same option of C<StandardInput>, see above.
3862              
3863             The C<fd:name> option connects standard output to a
3864             specific, named file descriptor provided by a socket unit. A name may be specified as part of this
3865             option, following a C<:> character
3866             (e.g. C<fd:foobar>). If no name is specified, the name
3867             C<stdout> is implied (i.e. C<fd> is equivalent to
3868             C<fd:stdout>). At least one socket unit defining the specified name must be provided
3869             via the C<Sockets> option, and the file descriptor name may differ from the name of
3870             its containing socket unit. If multiple matches are found, the first one will be used. See
3871             C<FileDescriptorName> in
3872             L<systemd.socket(5)>
3873             for more details about named descriptors and their ordering.
3874              
3875             If the standard output (or error output, see below) of a unit is connected to the journal or
3876             the kernel log buffer, the unit will implicitly gain a dependency of type C<After>
3877             on C<systemd-journald.socket> (also see the \"Implicit Dependencies\" section
3878             above). Also note that in this case stdout (or stderr, see below) will be an
3879             C<AF_UNIX> stream socket, and not a pipe or FIFO that can be re-opened. This means
3880             when executing shell scripts the construct echo \"hello\" > /dev/stderr for
3881             writing text to stderr will not work. To mitigate this use the construct echo \"hello\"
3882             >&2 instead, which is mostly equivalent and avoids this pitfall.
3883              
3884             This setting defaults to the value set with C<DefaultStandardOutput> in
3885             L<systemd-system.conf(5)>, which
3886             defaults to C<journal>. Note that setting this parameter might result in additional dependencies
3887             to be added to the unit (see above).",
3888             'type' => 'leaf',
3889             'value_type' => 'enum'
3890             },
3891             'StandardError',
3892             {
3893             'description' => 'Controls where file descriptor 2 (stderr) of the executed processes is connected to. The
3894             available options are identical to those of C<StandardOutput>, with some exceptions: if set to
3895             C<inherit> the file descriptor used for standard output is duplicated for standard error, while
3896             C<fd:name> will use a default file descriptor name of
3897             C<stderr>.
3898              
3899             This setting defaults to the value set with C<DefaultStandardError> in
3900             L<systemd-system.conf(5)>, which
3901             defaults to C<inherit>. Note that setting this parameter might result in additional dependencies
3902             to be added to the unit (see above).',
3903             'type' => 'leaf',
3904             'value_type' => 'uniline'
3905             },
3906             'StandardInputText',
3907             {
3908             'description' => 'Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to
3909             the executed processes. These settings have no effect unless C<StandardInput> is set
3910             to C<data> (which is the default if C<StandardInput> is not set
3911             otherwise, but C<StandardInputText>/C<StandardInputData> is). Use
3912             this option to embed process input data directly in the unit file.
3913              
3914             C<StandardInputText> accepts arbitrary textual data. C-style escapes for special
3915             characters as well as the usual C<%>-specifiers are resolved. Each time this setting is used
3916             the specified text is appended to the per-unit data buffer, followed by a newline character (thus every use
3917             appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines configured
3918             with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an
3919             empty line, add an additional C<\\n> to the end or beginning of a line).
3920              
3921             C<StandardInputData> accepts arbitrary binary data, encoded in L<Base64|https://tools.ietf.org/html/rfc2045#section-6.8>. No escape sequences or specifiers are
3922             resolved. Any whitespace in the encoded version is ignored during decoding.
3923              
3924             Note that C<StandardInputText> and C<StandardInputData> operate on the
3925             same data buffer, and may be mixed in order to configure both binary and textual data for the same input
3926             stream. The textual or binary data is joined strictly in the order the settings appear in the unit
3927             file. Assigning an empty string to either will reset the data buffer.
3928              
3929             Please keep in mind that in order to maintain readability long unit file settings may be split into
3930             multiple lines, by suffixing each line (except for the last) with a C<\\> character (see
3931             L<systemd.unit(5)> for
3932             details). This is particularly useful for large data configured with these two options. Example:',
3933             'type' => 'leaf',
3934             'value_type' => 'uniline'
3935             },
3936             'StandardInputData',
3937             {
3938             'description' => 'Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to
3939             the executed processes. These settings have no effect unless C<StandardInput> is set
3940             to C<data> (which is the default if C<StandardInput> is not set
3941             otherwise, but C<StandardInputText>/C<StandardInputData> is). Use
3942             this option to embed process input data directly in the unit file.
3943              
3944             C<StandardInputText> accepts arbitrary textual data. C-style escapes for special
3945             characters as well as the usual C<%>-specifiers are resolved. Each time this setting is used
3946             the specified text is appended to the per-unit data buffer, followed by a newline character (thus every use
3947             appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines configured
3948             with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an
3949             empty line, add an additional C<\\n> to the end or beginning of a line).
3950              
3951             C<StandardInputData> accepts arbitrary binary data, encoded in L<Base64|https://tools.ietf.org/html/rfc2045#section-6.8>. No escape sequences or specifiers are
3952             resolved. Any whitespace in the encoded version is ignored during decoding.
3953              
3954             Note that C<StandardInputText> and C<StandardInputData> operate on the
3955             same data buffer, and may be mixed in order to configure both binary and textual data for the same input
3956             stream. The textual or binary data is joined strictly in the order the settings appear in the unit
3957             file. Assigning an empty string to either will reset the data buffer.
3958              
3959             Please keep in mind that in order to maintain readability long unit file settings may be split into
3960             multiple lines, by suffixing each line (except for the last) with a C<\\> character (see
3961             L<systemd.unit(5)> for
3962             details). This is particularly useful for large data configured with these two options. Example:',
3963             'type' => 'leaf',
3964             'value_type' => 'uniline'
3965             },
3966             'LogLevelMax',
3967             {
3968             'description' => 'Configures filtering by log level of log messages generated by this unit. Takes a
3969             syslog log level, one of C<emerg> (lowest log level, only highest priority
3970             messages), C<alert>, C<crit>, C<err>, C<warning>,
3971             C<notice>, C<info>, C<debug> (highest log level, also lowest priority
3972             messages). See L<syslog(3)> for
3973             details. By default no filtering is applied (i.e. the default maximum log level is C<debug>). Use
3974             this option to configure the logging system to drop log messages of a specific service above the specified
3975             level. For example, set C<LogLevelMax>C<info> in order to turn off debug logging
3976             of a particularly chatty unit. Note that the configured level is applied to any log messages written by any
3977             of the processes belonging to this unit, as well as any log messages written by the system manager process
3978             (PID 1) in reference to this unit, sent via any supported logging protocol. The filtering is applied
3979             early in the logging pipeline, before any kind of further processing is done. Moreover, messages which pass
3980             through this filter successfully might still be dropped by filters applied at a later stage in the logging
3981             subsystem. For example, C<MaxLevelStore> configured in
3982             L<journald.conf(5)> might
3983             prohibit messages of higher log levels to be stored on disk, even though the per-unit
3984             C<LogLevelMax> permitted it to be processed.',
3985             'type' => 'leaf',
3986             'value_type' => 'uniline'
3987             },
3988             'LogExtraFields',
3989             {
3990             'description' => 'Configures additional log metadata fields to include in all log records generated by
3991             processes associated with this unit. This setting takes one or more journal field assignments in the
3992             format C<FIELD=VALUE> separated by whitespace. See
3993             L<systemd.journal-fields(7)>
3994             for details on the journal field concept. Even though the underlying journal implementation permits
3995             binary field values, this setting accepts only valid UTF-8 values. To include space characters in a
3996             journal field value, enclose the assignment in double quotes (").
3997             The usual specifiers are expanded in all assignments (see below). Note that this setting is not only
3998             useful for attaching additional metadata to log records of a unit, but given that all fields and
3999             values are indexed may also be used to implement cross-unit log record matching. Assign an empty
4000             string to reset the list.',
4001             'type' => 'leaf',
4002             'value_type' => 'uniline'
4003             },
4004             'LogRateLimitIntervalSec',
4005             {
4006             'description' => 'Configures the rate limiting that is applied to messages generated by this unit. If, in the
4007             time interval defined by C<LogRateLimitIntervalSec>, more messages than specified in
4008             C<LogRateLimitBurst> are logged by a service, all further messages within the interval are
4009             dropped until the interval is over. A message about the number of dropped messages is generated. The time
4010             specification for C<LogRateLimitIntervalSec> may be specified in the following units: "s",
4011             "min", "h", "ms", "us" (see
4012             L<systemd.time(7)> for details).
4013             The default settings are set by C<RateLimitIntervalSec> and C<RateLimitBurst>
4014             configured in L<journald.conf(5)>.
4015             ',
4016             'type' => 'leaf',
4017             'value_type' => 'uniline'
4018             },
4019             'LogRateLimitBurst',
4020             {
4021             'description' => 'Configures the rate limiting that is applied to messages generated by this unit. If, in the
4022             time interval defined by C<LogRateLimitIntervalSec>, more messages than specified in
4023             C<LogRateLimitBurst> are logged by a service, all further messages within the interval are
4024             dropped until the interval is over. A message about the number of dropped messages is generated. The time
4025             specification for C<LogRateLimitIntervalSec> may be specified in the following units: "s",
4026             "min", "h", "ms", "us" (see
4027             L<systemd.time(7)> for details).
4028             The default settings are set by C<RateLimitIntervalSec> and C<RateLimitBurst>
4029             configured in L<journald.conf(5)>.
4030             ',
4031             'type' => 'leaf',
4032             'value_type' => 'uniline'
4033             },
4034             'LogNamespace',
4035             {
4036             'description' => 'Run the unit\'s processes in the specified journal namespace. Expects a short
4037             user-defined string identifying the namespace. If not used the processes of the service are run in
4038             the default journal namespace, i.e. their log stream is collected and processed by
4039             C<systemd-journald.service>. If this option is used any log data generated by
4040             processes of this unit (regardless if via the syslog(), journal native logging
4041             or stdout/stderr logging) is collected and processed by an instance of the
4042             C<systemd-journald@.service> template unit, which manages the specified
4043             namespace. The log data is stored in a data store independent from the default log namespace\'s data
4044             store. See
4045             L<systemd-journald.service(8)>
4046             for details about journal namespaces.
4047              
4048             Internally, journal namespaces are implemented through Linux mount namespacing and
4049             over-mounting the directory that contains the relevant C<AF_UNIX> sockets used for
4050             logging in the unit\'s mount namespace. Since mount namespaces are used this setting disconnects
4051             propagation of mounts from the unit\'s processes to the host, similar to how
4052             C<ReadOnlyPaths> and similar settings (see above) work. Journal namespaces may hence
4053             not be used for services that need to establish mount points on the host.
4054              
4055             When this option is used the unit will automatically gain ordering and requirement dependencies
4056             on the two socket units associated with the C<systemd-journald@.service> instance
4057             so that they are automatically established prior to the unit starting up. Note that when this option
4058             is used log output of this service does not appear in the regular
4059             L<journalctl(1)>
4060             output, unless the C<--namespace=> option is used.',
4061             'type' => 'leaf',
4062             'value_type' => 'uniline'
4063             },
4064             'SyslogIdentifier',
4065             {
4066             'description' => 'Sets the process name ("syslog tag") to prefix log lines sent to
4067             the logging system or the kernel log buffer with. If not set, defaults to the process name of the
4068             executed process. This option is only useful when C<StandardOutput> or
4069             C<StandardError> are set to C<journal> or C<kmsg> (or to
4070             the same settings in combination with C<+console>) and only applies to log messages
4071             written to stdout or stderr.',
4072             'type' => 'leaf',
4073             'value_type' => 'uniline'
4074             },
4075             'SyslogFacility',
4076             {
4077             'description' => 'Sets the syslog facility identifier to use when logging. One of
4078             C<kern>, C<user>, C<mail>, C<daemon>,
4079             C<auth>, C<syslog>, C<lpr>, C<news>,
4080             C<uucp>, C<cron>, C<authpriv>, C<ftp>,
4081             C<local0>, C<local1>, C<local2>, C<local3>,
4082             C<local4>, C<local5>, C<local6> or
4083             C<local7>. See L<syslog(3)> for
4084             details. This option is only useful when C<StandardOutput> or
4085             C<StandardError> are set to C<journal> or C<kmsg> (or to
4086             the same settings in combination with C<+console>), and only applies to log messages
4087             written to stdout or stderr. Defaults to C<daemon>.',
4088             'type' => 'leaf',
4089             'value_type' => 'uniline'
4090             },
4091             'SyslogLevel',
4092             {
4093             'description' => 'The default syslog log level to use when logging to the logging system or
4094             the kernel log buffer. One of C<emerg>, C<alert>, C<crit>,
4095             C<err>, C<warning>, C<notice>, C<info>,
4096             C<debug>. See L<syslog(3)> for
4097             details. This option is only useful when C<StandardOutput> or
4098             C<StandardError> are set to C<journal> or
4099             C<kmsg> (or to the same settings in combination with C<+console>), and only applies
4100             to log messages written to stdout or stderr. Note that individual lines output by executed processes may be
4101             prefixed with a different log level which can be used to override the default log level specified here. The
4102             interpretation of these prefixes may be disabled with C<SyslogLevelPrefix>, see below. For
4103             details, see L<sd-daemon(3)>.
4104             Defaults to C<info>.',
4105             'type' => 'leaf',
4106             'value_type' => 'uniline'
4107             },
4108             'SyslogLevelPrefix',
4109             {
4110             'description' => 'Takes a boolean argument. If true and C<StandardOutput> or
4111             C<StandardError> are set to C<journal> or C<kmsg> (or to
4112             the same settings in combination with C<+console>), log lines written by the executed
4113             process that are prefixed with a log level will be processed with this log level set but the prefix
4114             removed. If set to false, the interpretation of these prefixes is disabled and the logged lines are
4115             passed on as-is. This only applies to log messages written to stdout or stderr. For details about
4116             this prefixing see
4117             L<sd-daemon(3)>.
4118             Defaults to true.',
4119             'type' => 'leaf',
4120             'value_type' => 'boolean',
4121             'write_as' => [
4122             'no',
4123             'yes'
4124             ]
4125             },
4126             'TTYPath',
4127             {
4128             'description' => 'Sets the terminal device node to use if standard input, output, or error are connected to a TTY
4129             (see above). Defaults to C</dev/console>.',
4130             'type' => 'leaf',
4131             'value_type' => 'uniline'
4132             },
4133             'TTYReset',
4134             {
4135             'description' => 'Reset the terminal device specified with C<TTYPath> before and after
4136             execution. Defaults to C<no>.',
4137             'type' => 'leaf',
4138             'value_type' => 'uniline'
4139             },
4140             'TTYVHangup',
4141             {
4142             'description' => 'Disconnect all clients which have opened the terminal device specified with
4143             C<TTYPath> before and after execution. Defaults to C<no>.',
4144             'type' => 'leaf',
4145             'value_type' => 'uniline'
4146             },
4147             'TTYRows',
4148             {
4149             'description' => 'Configure the size of the TTY specified with C<TTYPath>. If unset or
4150             set to the empty string, the kernel default is used.',
4151             'type' => 'leaf',
4152             'value_type' => 'uniline'
4153             },
4154             'TTYColumns',
4155             {
4156             'description' => 'Configure the size of the TTY specified with C<TTYPath>. If unset or
4157             set to the empty string, the kernel default is used.',
4158             'type' => 'leaf',
4159             'value_type' => 'uniline'
4160             },
4161             'TTYVTDisallocate',
4162             {
4163             'description' => 'If the terminal device specified with C<TTYPath> is a virtual console
4164             terminal, try to deallocate the TTY before and after execution. This ensures that the screen and scrollback
4165             buffer is cleared. Defaults to C<no>.',
4166             'type' => 'leaf',
4167             'value_type' => 'uniline'
4168             },
4169             'LoadCredential',
4170             {
4171             'description' => "Pass a credential to the unit. Credentials are limited-size binary or textual objects
4172             that may be passed to unit processes. They are primarily used for passing cryptographic keys (both
4173             public and private) or certificates, user account information or identity information from host to
4174             services. The data is accessible from the unit's processes via the file system, at a read-only
4175             location that (if possible and permitted) is backed by non-swappable memory. The data is only
4176             accessible to the user associated with the unit, via the
4177             C<User>/C<DynamicUser> settings (as well as the superuser). When
4178             available, the location of credentials is exported as the C<\$CREDENTIALS_DIRECTORY>
4179             environment variable to the unit's processes.
4180              
4181             The C<LoadCredential> setting takes a textual ID to use as name for a
4182             credential plus a file system path, separated by a colon. The ID must be a short ASCII string
4183             suitable as filename in the filesystem, and may be chosen freely by the user. If the specified path
4184             is absolute it is opened as regular file and the credential data is read from it. If the absolute
4185             path refers to an C<AF_UNIX> stream socket in the file system a connection is made
4186             to it (only once at unit start-up) and the credential data read from the connection, providing an
4187             easy IPC integration point for dynamically transferring credentials from other services.
4188              
4189             If the specified path is not absolute and itself qualifies as valid credential identifier it is
4190             attempted to find a credential that the service manager itself received under the specified name \x{2014}
4191             which may be used to propagate credentials from an invoking environment (e.g. a container manager
4192             that invoked the service manager) into a service. If no matching system credential is found, the
4193             directories C</etc/credstore/>, C</run/credstore/> and
4194             C</usr/lib/credstore/> are searched for files under the credential's name \x{2014} which
4195             hence are recommended locations for credential data on disk. If
4196             C<LoadCredentialEncrypted> is used C</run/credstore.encrypted/>,
4197             C</etc/credstore.encrypted/>, and
4198             C</usr/lib/credstore.encrypted/> are searched as well.
4199              
4200             If the file system path is omitted it is chosen identical to the credential name, i.e. this is
4201             a terse way to declare credentials to inherit from the service manager into a service. This option
4202             may be used multiple times, each time defining an additional credential to pass to the unit.
4203              
4204             If an absolute path referring to a directory is specified, every file in that directory
4205             (recursively) will be loaded as a separate credential. The ID for each credential will be the
4206             provided ID suffixed with C<_\$FILENAME> (e.g., C<Key_file1>). When
4207             loading from a directory, symlinks will be ignored.
4208              
4209             The contents of the file/socket may be arbitrary binary or textual data, including newline
4210             characters and C<NUL> bytes.
4211              
4212             The C<LoadCredentialEncrypted> setting is identical to
4213             C<LoadCredential>, except that the credential data is decrypted and authenticated
4214             before being passed on to the executed processes. Specifically, the referenced path should refer to a
4215             file or socket with an encrypted credential, as implemented by
4216             L<systemd-creds(1)>. This
4217             credential is loaded, decrypted, authenticated and then passed to the application in plaintext form,
4218             in the same way a regular credential specified via C<LoadCredential> would be. A
4219             credential configured this way may be symmetrically encrypted/authenticated with a secret key derived
4220             from the system's TPM2 security chip, or with a secret key stored in
4221             C</var/lib/systemd/credentials.secret>, or with both. Using encrypted and
4222             authenticated credentials improves security as credentials are not stored in plaintext and only
4223             authenticated and decrypted into plaintext the moment a service requiring them is started. Moreover,
4224             credentials may be bound to the local hardware and installations, so that they cannot easily be
4225             analyzed offline, or be generated externally.
4226              
4227             The credential files/IPC sockets must be accessible to the service manager, but don't have to
4228             be directly accessible to the unit's processes: the credential data is read and copied into separate,
4229             read-only copies for the unit that are accessible to appropriately privileged processes. This is
4230             particularly useful in combination with C<DynamicUser> as this way privileged data
4231             can be made available to processes running under a dynamic UID (i.e. not a previously known one)
4232             without having to open up access to all users.
4233              
4234             In order to reference the path a credential may be read from within a
4235             C<ExecStart> command line use C<\${CREDENTIALS_DIRECTORY}/mycred>,
4236             e.g. C<ExecStart=cat \${CREDENTIALS_DIRECTORY}/mycred>. In order to reference the path
4237             a credential may be read from within a C<Environment> line use
4238             C<%d/mycred>, e.g. C<Environment=MYCREDPATH=%d/mycred>.
4239              
4240             Currently, an accumulated credential size limit of 1 MB per unit is enforced.
4241              
4242             The service manager itself may receive system credentials that can be propagated to services
4243             from a hosting container manager or VM hypervisor. See the L<Container Interface|https://systemd.io/CONTAINER_INTERFACE> documentation for details
4244             about the former. For the latter, use the qemu C<fw_cfg> node
4245             C<opt/io.systemd.credentials/>. Example qemu switch: C<-fw_cfg
4246             name=opt/io.systemd.credentials/mycred,string=supersecret>. They may also be specified on
4247             the kernel command line using the C<systemd.set_credential=> switch (see
4248             L<systemd(1)>)
4249             and from the UEFI firmware environment via
4250             L<systemd-stub(7)>.
4251              
4252             If referencing an C<AF_UNIX> stream socket to connect to, the connection will
4253             originate from an abstract namespace socket, that includes information about the unit and the
4254             credential ID in its socket name. Use L<getpeername(2)>
4255             to query this information. The returned socket name is formatted as C<NUL>RANDOM C</unit/> UNITC</> ID, i.e. a C<NUL> byte (as required
4256             for abstract namespace socket names), followed by a random string (consisting of alphadecimal
4257             characters), followed by the literal string C</unit/>, followed by the requesting
4258             unit name, followed by the literal character C</>, followed by the textual credential
4259             ID requested. Example: C<\\0adf9d86b6eda275e/unit/foobar.service/credx> in case the
4260             credential C<credx> is requested for a unit C<foobar.service>. This
4261             functionality is useful for using a single listening socket to serve credentials to multiple
4262             consumers.
4263              
4264             For further information see L<System and Service
4265             Credentials|https://systemd.io/CREDENTIALS> documentation.",
4266             'type' => 'leaf',
4267             'value_type' => 'uniline'
4268             },
4269             'LoadCredentialEncrypted',
4270             {
4271             'description' => "Pass a credential to the unit. Credentials are limited-size binary or textual objects
4272             that may be passed to unit processes. They are primarily used for passing cryptographic keys (both
4273             public and private) or certificates, user account information or identity information from host to
4274             services. The data is accessible from the unit's processes via the file system, at a read-only
4275             location that (if possible and permitted) is backed by non-swappable memory. The data is only
4276             accessible to the user associated with the unit, via the
4277             C<User>/C<DynamicUser> settings (as well as the superuser). When
4278             available, the location of credentials is exported as the C<\$CREDENTIALS_DIRECTORY>
4279             environment variable to the unit's processes.
4280              
4281             The C<LoadCredential> setting takes a textual ID to use as name for a
4282             credential plus a file system path, separated by a colon. The ID must be a short ASCII string
4283             suitable as filename in the filesystem, and may be chosen freely by the user. If the specified path
4284             is absolute it is opened as regular file and the credential data is read from it. If the absolute
4285             path refers to an C<AF_UNIX> stream socket in the file system a connection is made
4286             to it (only once at unit start-up) and the credential data read from the connection, providing an
4287             easy IPC integration point for dynamically transferring credentials from other services.
4288              
4289             If the specified path is not absolute and itself qualifies as valid credential identifier it is
4290             attempted to find a credential that the service manager itself received under the specified name \x{2014}
4291             which may be used to propagate credentials from an invoking environment (e.g. a container manager
4292             that invoked the service manager) into a service. If no matching system credential is found, the
4293             directories C</etc/credstore/>, C</run/credstore/> and
4294             C</usr/lib/credstore/> are searched for files under the credential's name \x{2014} which
4295             hence are recommended locations for credential data on disk. If
4296             C<LoadCredentialEncrypted> is used C</run/credstore.encrypted/>,
4297             C</etc/credstore.encrypted/>, and
4298             C</usr/lib/credstore.encrypted/> are searched as well.
4299              
4300             If the file system path is omitted it is chosen identical to the credential name, i.e. this is
4301             a terse way to declare credentials to inherit from the service manager into a service. This option
4302             may be used multiple times, each time defining an additional credential to pass to the unit.
4303              
4304             If an absolute path referring to a directory is specified, every file in that directory
4305             (recursively) will be loaded as a separate credential. The ID for each credential will be the
4306             provided ID suffixed with C<_\$FILENAME> (e.g., C<Key_file1>). When
4307             loading from a directory, symlinks will be ignored.
4308              
4309             The contents of the file/socket may be arbitrary binary or textual data, including newline
4310             characters and C<NUL> bytes.
4311              
4312             The C<LoadCredentialEncrypted> setting is identical to
4313             C<LoadCredential>, except that the credential data is decrypted and authenticated
4314             before being passed on to the executed processes. Specifically, the referenced path should refer to a
4315             file or socket with an encrypted credential, as implemented by
4316             L<systemd-creds(1)>. This
4317             credential is loaded, decrypted, authenticated and then passed to the application in plaintext form,
4318             in the same way a regular credential specified via C<LoadCredential> would be. A
4319             credential configured this way may be symmetrically encrypted/authenticated with a secret key derived
4320             from the system's TPM2 security chip, or with a secret key stored in
4321             C</var/lib/systemd/credentials.secret>, or with both. Using encrypted and
4322             authenticated credentials improves security as credentials are not stored in plaintext and only
4323             authenticated and decrypted into plaintext the moment a service requiring them is started. Moreover,
4324             credentials may be bound to the local hardware and installations, so that they cannot easily be
4325             analyzed offline, or be generated externally.
4326              
4327             The credential files/IPC sockets must be accessible to the service manager, but don't have to
4328             be directly accessible to the unit's processes: the credential data is read and copied into separate,
4329             read-only copies for the unit that are accessible to appropriately privileged processes. This is
4330             particularly useful in combination with C<DynamicUser> as this way privileged data
4331             can be made available to processes running under a dynamic UID (i.e. not a previously known one)
4332             without having to open up access to all users.
4333              
4334             In order to reference the path a credential may be read from within a
4335             C<ExecStart> command line use C<\${CREDENTIALS_DIRECTORY}/mycred>,
4336             e.g. C<ExecStart=cat \${CREDENTIALS_DIRECTORY}/mycred>. In order to reference the path
4337             a credential may be read from within a C<Environment> line use
4338             C<%d/mycred>, e.g. C<Environment=MYCREDPATH=%d/mycred>.
4339              
4340             Currently, an accumulated credential size limit of 1 MB per unit is enforced.
4341              
4342             The service manager itself may receive system credentials that can be propagated to services
4343             from a hosting container manager or VM hypervisor. See the L<Container Interface|https://systemd.io/CONTAINER_INTERFACE> documentation for details
4344             about the former. For the latter, use the qemu C<fw_cfg> node
4345             C<opt/io.systemd.credentials/>. Example qemu switch: C<-fw_cfg
4346             name=opt/io.systemd.credentials/mycred,string=supersecret>. They may also be specified on
4347             the kernel command line using the C<systemd.set_credential=> switch (see
4348             L<systemd(1)>)
4349             and from the UEFI firmware environment via
4350             L<systemd-stub(7)>.
4351              
4352             If referencing an C<AF_UNIX> stream socket to connect to, the connection will
4353             originate from an abstract namespace socket, that includes information about the unit and the
4354             credential ID in its socket name. Use L<getpeername(2)>
4355             to query this information. The returned socket name is formatted as C<NUL>RANDOM C</unit/> UNITC</> ID, i.e. a C<NUL> byte (as required
4356             for abstract namespace socket names), followed by a random string (consisting of alphadecimal
4357             characters), followed by the literal string C</unit/>, followed by the requesting
4358             unit name, followed by the literal character C</>, followed by the textual credential
4359             ID requested. Example: C<\\0adf9d86b6eda275e/unit/foobar.service/credx> in case the
4360             credential C<credx> is requested for a unit C<foobar.service>. This
4361             functionality is useful for using a single listening socket to serve credentials to multiple
4362             consumers.
4363              
4364             For further information see L<System and Service
4365             Credentials|https://systemd.io/CREDENTIALS> documentation.",
4366             'type' => 'leaf',
4367             'value_type' => 'uniline'
4368             },
4369             'SetCredential',
4370             {
4371             'description' => 'The C<SetCredential> setting is similar to
4372             C<LoadCredential> but accepts a literal value to use as data for the credential,
4373             instead of a file system path to read the data from. Do not use this option for data that is supposed
4374             to be secret, as it is accessible to unprivileged processes via IPC. It\'s only safe to use this for
4375             user IDs, public key material and similar non-sensitive data. For everything else use
4376             C<LoadCredential>. In order to embed binary data into the credential data use
4377             C-style escaping (i.e. C<\\n> to embed a newline, or C<\\x00> to embed
4378             a C<NUL> byte).
4379              
4380             The C<SetCredentialEncrypted> setting is identical to
4381             C<SetCredential> but expects an encrypted credential in literal form as value. This
4382             allows embedding confidential credentials securely directly in unit files. Use
4383             L<systemd-creds(1)>\'
4384             C<-p> switch to generate suitable C<SetCredentialEncrypted> lines
4385             directly from plaintext credentials. For further details see
4386             C<LoadCredentialEncrypted> above.
4387              
4388             If a credential of the same ID is listed in both C<LoadCredential> and
4389             C<SetCredential>, the latter will act as default if the former cannot be
4390             retrieved. In this case not being able to retrieve the credential from the path specified in
4391             C<LoadCredential> is not considered fatal.',
4392             'type' => 'leaf',
4393             'value_type' => 'uniline'
4394             },
4395             'SetCredentialEncrypted',
4396             {
4397             'description' => 'The C<SetCredential> setting is similar to
4398             C<LoadCredential> but accepts a literal value to use as data for the credential,
4399             instead of a file system path to read the data from. Do not use this option for data that is supposed
4400             to be secret, as it is accessible to unprivileged processes via IPC. It\'s only safe to use this for
4401             user IDs, public key material and similar non-sensitive data. For everything else use
4402             C<LoadCredential>. In order to embed binary data into the credential data use
4403             C-style escaping (i.e. C<\\n> to embed a newline, or C<\\x00> to embed
4404             a C<NUL> byte).
4405              
4406             The C<SetCredentialEncrypted> setting is identical to
4407             C<SetCredential> but expects an encrypted credential in literal form as value. This
4408             allows embedding confidential credentials securely directly in unit files. Use
4409             L<systemd-creds(1)>\'
4410             C<-p> switch to generate suitable C<SetCredentialEncrypted> lines
4411             directly from plaintext credentials. For further details see
4412             C<LoadCredentialEncrypted> above.
4413              
4414             If a credential of the same ID is listed in both C<LoadCredential> and
4415             C<SetCredential>, the latter will act as default if the former cannot be
4416             retrieved. In this case not being able to retrieve the credential from the path specified in
4417             C<LoadCredential> is not considered fatal.',
4418             'type' => 'leaf',
4419             'value_type' => 'uniline'
4420             },
4421             'UtmpIdentifier',
4422             {
4423             'description' => 'Takes a four character identifier string for an L<utmp(5)> and wtmp entry
4424             for this service. This should only be set for services such as getty implementations (such
4425             as L<agetty(8)>) where utmp/wtmp
4426             entries must be created and cleared before and after execution, or for services that shall be executed as if
4427             they were run by a getty process (see below). If the configured string is longer than four
4428             characters, it is truncated and the terminal four characters are used. This setting interprets %I style string
4429             replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this
4430             service.',
4431             'type' => 'leaf',
4432             'value_type' => 'uniline'
4433             },
4434             'UtmpMode',
4435             {
4436             'choice' => [
4437             'init',
4438             'login',
4439             'user'
4440             ],
4441             'description' => 'Takes one of C<init>, C<login> or C<user>. If
4442             C<UtmpIdentifier> is set, controls which type of L<utmp(5)>/wtmp entries
4443             for this service are generated. This setting has no effect unless C<UtmpIdentifier> is set
4444             too. If C<init> is set, only an C<INIT_PROCESS> entry is generated and the
4445             invoked process must implement a getty-compatible utmp/wtmp logic. If
4446             C<login> is set, first an C<INIT_PROCESS> entry, followed by a
4447             C<LOGIN_PROCESS> entry is generated. In this case, the invoked process must implement a
4448             L<login(1)>-compatible
4449             utmp/wtmp logic. If C<user> is set, first an C<INIT_PROCESS> entry, then a
4450             C<LOGIN_PROCESS> entry and finally a C<USER_PROCESS> entry is
4451             generated. In this case, the invoked process may be any process that is suitable to be run as session
4452             leader. Defaults to C<init>.',
4453             'type' => 'leaf',
4454             'value_type' => 'enum'
4455             }
4456             ],
4457             'generated_by' => 'parse-man.pl from systemd 250 doc',
4458             'license' => 'LGPLv2.1+',
4459             'name' => 'Systemd::Common::Exec'
4460             }
4461             ]
4462             ;
4463