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