1SYSTEMD.SPECIAL(7) systemd.special SYSTEMD.SPECIAL(7)
2
6 systemd.special - Special systemd units
7
9 basic.target, bluetooth.target, cryptsetup-pre.target,
10 cryptsetup.target, veritysetup-pre.target, veritysetup.target,
11 ctrl-alt-del.target, blockdev@.target, boot-complete.target,
12 default.target, emergency.target, exit.target, factory-reset.target,
13 final.target, first-boot-complete.target, getty.target,
14 getty-pre.target, graphical.target, halt.target, hibernate.target,
15 hybrid-sleep.target, suspend-then-hibernate.target, initrd.target,
16 initrd-fs.target, initrd-root-device.target, initrd-root-fs.target,
17 initrd-usr-fs.target, integritysetup-pre.target, integritysetup.target,
18 kbrequest.target, kexec.target, local-fs-pre.target, local-fs.target,
19 machines.target multi-user.target, network-online.target,
20 network-pre.target, network.target, nss-lookup.target,
21 nss-user-lookup.target, paths.target, poweroff.target, printer.target,
22 reboot.target, remote-cryptsetup.target, remote-veritysetup.target,
23 remote-fs-pre.target, remote-fs.target, rescue.target, rpcbind.target,
24 runlevel2.target, runlevel3.target, runlevel4.target, runlevel5.target,
25 shutdown.target, sigpwr.target, sleep.target, slices.target,
26 smartcard.target, sockets.target, soft-reboot.target, sound.target,
27 suspend.target, swap.target, sysinit.target, system-update.target,
28 system-update-pre.target, time-set.target, time-sync.target,
29 timers.target, umount.target, usb-gadget.target, -.slice, system.slice,
30 user.slice, machine.slice, -.mount, dbus.service, dbus.socket,
31 display-manager.service, init.scope, syslog.socket,
32 system-update-cleanup.service
33
35 A few units are treated specially by systemd. Many of them have special
36 internal semantics and cannot be renamed, while others simply have a
37 standard meaning and should be present on all systems.
38
40 Special System Units
41 -.mount
42 The root mount point, i.e. the mount unit for the / path. This unit
43 is unconditionally active, during the entire time the system is up,
44 as this mount point is where the basic userspace is running from.
45 basic.target
47 A special target unit covering basic boot-up.
48 systemd automatically adds dependency of the type After= for this
50 target unit to all services (except for those with
51 DefaultDependencies=no).
52 Usually, this should pull-in all local mount points plus /var/,
54 /tmp/ and /var/tmp/, swap devices, sockets, timers, path units and
55 other basic initialization necessary for general purpose daemons.
56 The mentioned mount points are special cased to allow them to be
57 remote.
58 This target usually does not pull in any non-target units directly,
60 but rather does so indirectly via other early boot targets. It is
61 instead meant as a synchronization point for late boot services.
62 Refer to bootup(7) for details on the targets involved.
63 boot-complete.target
65 This target is intended as generic synchronization point for
66 services that shall determine or act on whether the boot process
67 completed successfully. Order units that are required to succeed
68 for a boot process to be considered successful before this unit,
69 and add a Requires= dependency from the target unit to them. Order
70 units that shall only run when the boot process is considered
71 successful after the target unit and pull in the target from it,
72 also with Requires=. Note that by default this target unit is not
73 part of the initial boot transaction, but is supposed to be pulled
74 in only if required by units that want to run only on successful
75 boots.
76 See systemd-boot-check-no-failures.service(8) for a service that
78 implements a generic system health check and orders itself before
79 boot-complete.target.
80 See systemd-bless-boot.service(8) for a service that propagates
82 boot success information to the boot loader, and orders itself
83 after boot-complete.target.
84 ctrl-alt-del.target
86 systemd starts this target whenever Control+Alt+Del is pressed on
87 the console. Usually, this should be aliased (symlinked) to
88 reboot.target.
89 cryptsetup.target
91 A target that pulls in setup services for all encrypted block
92 devices.
93 veritysetup.target
95 A target that pulls in setup services for all verity integrity
96 protected block devices.
97 dbus.service
99 A special unit for the D-Bus bus daemon. As soon as this service is
100 fully started up systemd will connect to it and register its
101 service.
102 dbus.socket
104 A special unit for the D-Bus system bus socket. All units with
105 Type=dbus automatically gain a dependency on this unit.
106 default.target
108 The default unit systemd starts at bootup. Usually, this should be
109 aliased (symlinked) to multi-user.target or graphical.target. See
110 bootup(7) for more discussion.
111 The default unit systemd starts at bootup can be overridden with
113 the systemd.unit= kernel command line option, or more conveniently,
114 with the short names like single, rescue, 1, 3, 5, ...; see
115 systemd(1).
116 display-manager.service
118 The display manager service. Usually, this should be aliased
119 (symlinked) to gdm.service or a similar display manager service.
120 emergency.target
122 A special target unit that starts an emergency shell on the main
123 console. This target does not pull in other services or mounts. It
124 is the most minimal version of starting the system in order to
125 acquire an interactive shell; the only processes running are
126 usually just the system manager (PID 1) and the shell process. This
127 unit may be used by specifying emergency on the kernel command
128 line; it is also used when a file system check on a required file
129 system fails and boot-up cannot continue. Compare with
130 rescue.target, which serves a similar purpose, but also starts the
131 most basic services and mounts all file systems.
132 In many ways booting into emergency.target is similar to the effect
134 of booting with "init=/bin/sh" on the kernel command line, except
135 that emergency mode provides you with the full system and service
136 manager, and allows starting individual units in order to continue
137 the boot process in steps.
138 Note that depending on how emergency.target is reached, the root
140 file system might be mounted read-only or read-write (no remounting
141 is done specially for this target). For example, the system may
142 boot with root mounted read-only when ro is used on the kernel
143 command line and remain this way for emergency.target, or the
144 system may transition to emergency.target after the system has been
145 partially booted and disks have already been remounted read-write.
146 exit.target
148 A special service unit for shutting down the system or user service
149 manager. It is equivalent to poweroff.target on non-container
150 systems, and also works in containers.
151 systemd will start this unit when it receives the SIGTERM or SIGINT
153 signal when running as user service daemon.
154 Normally, this (indirectly) pulls in shutdown.target, which in turn
156 should be conflicted by all units that want to be scheduled for
157 shutdown when the service manager starts to exit.
158 factory-reset.target
160 A special target to trigger a factory reset.
161 final.target
163 A special target unit that is used during the shutdown logic and
164 may be used to pull in late services after all normal services are
165 already terminated and all mounts unmounted.
166 getty.target
168 A special target unit that pulls in statically configured local TTY
169 getty instances.
170 graphical.target
172 A special target unit for setting up a graphical login screen. This
173 pulls in multi-user.target.
174 Units that are needed for graphical logins shall add Wants=
176 dependencies for their unit to this unit (or multi-user.target)
177 during installation. This is best configured via
178 WantedBy=graphical.target in the unit's [Install] section.
179 hibernate.target
181 A special target unit for hibernating the system. This pulls in
182 sleep.target.
183 hybrid-sleep.target
185 A special target unit for hibernating and suspending the system at
186 the same time. This pulls in sleep.target.
187 suspend-then-hibernate.target
189 A special target unit for suspending the system for a period of
190 time, waking it and putting it into hibernate. This pulls in
191 sleep.target.
192 halt.target
194 A special target unit for shutting down and halting the system.
195 Note that this target is distinct from poweroff.target in that it
196 generally really just halts the system rather than powering it
197 down.
198 Applications wanting to halt the system should not start this unit
200 directly, but should instead execute systemctl halt (possibly with
201 the --no-block option) or call systemd(1)'s
202 org.freedesktop.systemd1.Manager.Halt D-Bus method directly.
203 init.scope
205 This scope unit is where the system and service manager (PID 1)
206 itself resides. It is active as long as the system is running.
207 initrd.target
209 This is the default target in the initrd, similar to default.target
210 in the main system. It is used to mount the real root and
211 transition to it. See bootup(7) for more discussion.
212 initrd-fs.target
214 systemd-fstab-generator(3) automatically adds dependencies of type
215 Before= to sysroot-usr.mount and all mount points found in
216 /etc/fstab that have the x-initrd.mount mount option set and do not
217 have the noauto mount option set. It is also indirectly ordered
218 after sysroot.mount. Thus, once this target is reached the
219 /sysroot/ hierarchy is fully set up, in preparation for the
220 transition to the host OS.
221 initrd-root-device.target
223 A special initrd target unit that is reached when the root
224 filesystem device is available, but before it has been mounted.
225 systemd-fstab-generator(3) and systemd-gpt-auto-generator(3)
226 automatically setup the appropriate dependencies to make this
227 happen.
228 initrd-root-fs.target
230 systemd-fstab-generator(3) automatically adds dependencies of type
231 Before= to the sysroot.mount unit, which is generated from the
232 kernel command line's root= setting (or equivalent).
233 initrd-usr-fs.target
235 systemd-fstab-generator(3) automatically adds dependencies of type
236 Before= to the sysusr-usr.mount unit, which is generated from the
237 kernel command line's usr= switch. Services may order themselves
238 after this target unit in order to run once the /sysusr/ hierarchy
239 becomes available, on systems that come up initially without a root
240 file system, but with an initialized /usr/ and need to access that
241 before setting up the root file system to ultimately switch to. On
242 systems where usr= is not used this target is ordered after
243 sysroot.mount and thus mostly equivalent to initrd-root-fs.target.
244 In effect on any system once this target is reached the file system
245 backing /usr/ is mounted, though possibly at two different
246 locations, either below the /sysusr/ or the /sysroot/ hierarchies.
247 kbrequest.target
249 systemd starts this target whenever Alt+ArrowUp is pressed on the
250 console. Note that any user with physical access to the machine
251 will be able to do this, without authentication, so this should be
252 used carefully.
253 kexec.target
255 A special target unit for shutting down and rebooting the system
256 via kexec.
257 Applications wanting to reboot the system should not start this
259 unit directly, but should instead execute systemctl kexec (possibly
260 with the --no-block option) or call systemd-logind(8)'s
261 org.freedesktop.login1.Manager.RebootWithFlags() D-Bus method
262 directly.
263 See systemd-kexec.service(8) for further details of the operation
265 this target pulls in.
266 local-fs.target
268 systemd-fstab-generator(3) automatically adds dependencies of type
269 Before= to all mount units that refer to local mount points for
270 this target unit. In addition, it adds dependencies of type Wants=
271 to this target unit for those mounts listed in /etc/fstab that have
272 the auto mount option set.
273 machines.target
275 A standard target unit for starting all the containers and other
276 virtual machines. See systemd-nspawn@.service for an example.
277 multi-user.target
279 A special target unit for setting up a multi-user system
280 (non-graphical). This is pulled in by graphical.target.
281 Units that are needed for a multi-user system shall add Wants=
283 dependencies for their unit to this unit during installation. This
284 is best configured via WantedBy=multi-user.target in the unit's
285 [Install] section.
286 network-online.target
288 Units that strictly require a configured network connection should
289 pull in network-online.target (via a Wants= type dependency) and
290 order themselves after it. This target unit is intended to pull in
291 a service that delays further execution until the network is
292 sufficiently set up. What precisely this requires is left to the
293 implementation of the network managing service.
294 Note the distinction between this unit and network.target. This
296 unit is an active unit (i.e. pulled in by the consumer rather than
297 the provider of this functionality) and pulls in a service which
298 possibly adds substantial delays to further execution. In contrast,
299 network.target is a passive unit (i.e. pulled in by the provider of
300 the functionality, rather than the consumer) that usually does not
301 delay execution much. Usually, network.target is part of the boot
302 of most systems, while network-online.target is not, except when at
303 least one unit requires it. Also see Running Services After the
304 Network Is Up[1] for more information.
305 All mount units for remote network file systems automatically pull
307 in this unit, and order themselves after it. Note that networking
308 daemons that simply provide functionality to other hosts (as
309 opposed to consume functionality of other hosts) generally do not
310 need to pull this in.
311 systemd automatically adds dependencies of type Wants= and After=
313 for this target unit to all SysV init script service units with an
314 LSB header referring to the "$network" facility.
315 Note that this unit is only useful during the original system
317 start-up logic. After the system has completed booting up, it will
318 not track the online state of the system anymore. Due to this it
319 cannot be used as a network connection monitor concept, it is
320 purely a one-time system start-up concept.
321 paths.target
323 A special target unit that sets up all path units (see
324 systemd.path(5) for details) that shall be active after boot.
325 It is recommended that path units installed by applications get
327 pulled in via Wants= dependencies from this unit. This is best
328 configured via a WantedBy=paths.target in the path unit's [Install]
329 section.
330 poweroff.target
332 A special target unit for shutting down and powering off the
333 system.
334 Applications wanting to power off the system should not start this
336 unit directly, but should instead execute systemctl poweroff
337 (possibly with the --no-block option) or call systemd-logind(8)'s
338 org.freedesktop.login1.Manager.PowerOff D-Bus method directly.
339 runlevel0.target is an alias for this target unit, for
341 compatibility with SysV.
342 reboot.target
344 A special target unit for shutting down and rebooting the system.
345 Applications wanting to reboot the system should not start this
347 unit directly, but should instead execute systemctl reboot
348 (possibly with the --no-block option) or call systemd-logind(8)'s
349 org.freedesktop.login1.Manager.Reboot() D-Bus method directly.
350 See systemd-reboot.service(8) for further details of the operation
352 this target pulls in.
353 runlevel6.target is an alias for this target unit, for
355 compatibility with SysV.
356 remote-cryptsetup.target
358 Similar to cryptsetup.target, but for encrypted devices which are
359 accessed over the network. It is used for crypttab(8) entries
360 marked with _netdev.
361 remote-veritysetup.target
363 Similar to veritysetup.target, but for verity integrity protected
364 devices which are accessed over the network. It is used for
365 veritytab(8) entries marked with _netdev.
366 remote-fs.target
368 Similar to local-fs.target, but for remote mount points.
369 systemd automatically adds dependencies of type After= for this
371 target unit to all SysV init script service units with an LSB
372 header referring to the "$remote_fs" facility.
373 rescue.target
375 A special target unit that pulls in the base system (including
376 system mounts) and spawns a rescue shell. Isolate to this target in
377 order to administer the system in single-user mode with all file
378 systems mounted but with no services running, except for the most
379 basic. Compare with emergency.target, which is much more reduced
380 and does not provide the file systems or most basic services.
381 Compare with multi-user.target, this target could be seen as
382 single-user.target.
383 runlevel1.target is an alias for this target unit, for
385 compatibility with SysV.
386 Use the "systemd.unit=rescue.target" kernel command line option to
388 boot into this mode. A short alias for this kernel command line
389 option is "1", for compatibility with SysV.
390 runlevel2.target, runlevel3.target, runlevel4.target, runlevel5.target
392 These are targets that are called whenever the SysV compatibility
393 code asks for runlevel 2, 3, 4, 5, respectively. It is a good idea
394 to make this an alias for (i.e. symlink to) graphical.target (for
395 runlevel 5) or multi-user.target (the others).
396 shutdown.target
398 A special target unit that terminates the services on system
399 shutdown.
400 Services that shall be terminated on system shutdown shall add
402 Conflicts= and Before= dependencies to this unit for their service
403 unit, which is implicitly done when DefaultDependencies=yes is set
404 (the default).
405 sigpwr.target
407 A special target that is started when systemd receives the SIGPWR
408 process signal, which is normally sent by the kernel or UPS daemons
409 when power fails.
410 sleep.target
412 A special target unit that is pulled in by suspend.target,
413 hibernate.target and hybrid-sleep.target and may be used to hook
414 units into the sleep state logic.
415 slices.target
417 A special target unit that sets up all slice units (see
418 systemd.slice(5) for details) that shall always be active after
419 boot. By default the generic system.slice slice unit as well as the
420 root slice unit -.slice are pulled in and ordered before this unit
421 (see below).
422 Adding slice units to slices.target is generally not necessary.
424 Instead, when some unit that uses Slice= is started, the specified
425 slice will be started automatically. Adding WantedBy=slices.target
426 lines to the [Install] section should only be done for units that
427 need to be always active. In that case care needs to be taken to
428 avoid creating a loop through the automatic dependencies on
429 "parent" slices.
430 sockets.target
432 A special target unit that sets up all socket units (see
433 systemd.socket(5) for details) that shall be active after boot.
434 Services that can be socket-activated shall add Wants= dependencies
436 to this unit for their socket unit during installation. This is
437 best configured via a WantedBy=sockets.target in the socket unit's
438 [Install] section.
439 soft-reboot.target
441 A special target unit for shutting down and rebooting the userspace
442 of the system (leaving the kernel running).
443 Applications wanting to reboot the system should not start this
445 unit directly, but should instead execute systemctl soft-reboot
446 (possibly with the --no-block option) or call systemd-logind(8)'s
447 org.freedesktop.login1.Manager.RebootWithFlags() D-Bus method
448 directly.
449 See systemd-soft-reboot.service(8) for further details of the
451 operation this target pulls in.
452 suspend.target
454 A special target unit for suspending the system. This pulls in
455 sleep.target.
456 swap.target
458 Similar to local-fs.target, but for swap partitions and swap files.
459 sysinit.target
461 systemd automatically adds dependencies of the types Requires= and
462 After= for this target unit to all services (except for those with
463 DefaultDependencies=no).
464 This target pulls in the services required for system
466 initialization. System services pulled in by this target should
467 declare DefaultDependencies=no and specify all their dependencies
468 manually, including access to anything more than a read only root
469 filesystem. For details on the dependencies of this target, refer
470 to bootup(7).
471 syslog.socket
473 The socket unit syslog implementations should listen on. All
474 userspace log messages will be made available on this socket. For
475 more information about syslog integration, please consult the
476 Syslog Interface[2] document.
477 system-update.target, system-update-pre.target,
479 system-update-cleanup.service
480 A special target unit that is used for offline system updates.
481 systemd-system-update-generator(8) will redirect the boot process
482 to this target if /system-update or /etc/system-update exists. For
483 more information see systemd.offline-updates(7).
484 Updates should happen before the system-update.target is reached,
486 and the services which implement them should cause the machine to
487 reboot. The main units executing the update should order themselves
488 after system-update-pre.target but not pull it in. Services which
489 want to run during system updates only, but before the actual
490 system update is executed should order themselves before this unit
491 and pull it in. As a safety measure, if this does not happen, and
492 /system-update or /etc/system-update still exists after
493 system-update.target is reached, system-update-cleanup.service will
494 remove the symlinks and reboot the machine.
495 timers.target
497 A special target unit that sets up all timer units (see
498 systemd.timer(5) for details) that shall be active after boot.
499 It is recommended that timer units installed by applications get
501 pulled in via Wants= dependencies from this unit. This is best
502 configured via WantedBy=timers.target in the timer unit's [Install]
503 section.
504 umount.target
506 A special target unit that unmounts all mount and automount points
507 on system shutdown.
508 Mounts that shall be unmounted on system shutdown shall add
510 Conflicts dependencies to this unit for their mount unit, which is
511 implicitly done when DefaultDependencies=yes is set (the default).
512 Special System Units for Devices
514 Some target units are automatically pulled in as devices of certain
515 kinds show up in the system. These may be used to automatically
516 activate various services based on the specific type of the available
517 hardware.
518 bluetooth.target
520 This target is started automatically as soon as a Bluetooth
521 controller is plugged in or becomes available at boot.
522 This may be used to pull in Bluetooth management daemons
524 dynamically when Bluetooth hardware is found.
525 printer.target
527 This target is started automatically as soon as a printer is
528 plugged in or becomes available at boot.
529 This may be used to pull in printer management daemons dynamically
531 when printer hardware is found.
532 smartcard.target
534 This target is started automatically as soon as a smartcard
535 controller is plugged in or becomes available at boot.
536 This may be used to pull in smartcard management daemons
538 dynamically when smartcard hardware is found.
539 sound.target
541 This target is started automatically as soon as a sound card is
542 plugged in or becomes available at boot.
543 This may be used to pull in audio management daemons dynamically
545 when audio hardware is found.
546 usb-gadget.target
548 This target is started automatically as soon as a USB Device
549 Controller becomes available at boot.
550 This may be used to pull in usb gadget dynamically when UDC
552 hardware is found.
553 Special Passive System Units
555 A number of special system targets are defined that can be used to
556 properly order boot-up of optional services. These targets are
557 generally not part of the initial boot transaction, unless they are
558 explicitly pulled in by one of the implementing services. Note
559 specifically that these passive target units are generally not pulled
560 in by the consumer of a service, but by the provider of the service.
561 This means: a consuming service should order itself after these targets
562 (as appropriate), but not pull it in. A providing service should order
563 itself before these targets (as appropriate) and pull it in (via a
564 Wants= type dependency).
565 Note that these passive units cannot be started manually, i.e.
567 "systemctl start time-sync.target" will fail with an error. They can
568 only be pulled in by dependency. This is enforced since they exist for
569 ordering purposes only and thus are not useful as only unit within a
570 transaction.
571 blockdev@.target
573 This template unit is used to order mount units and other consumers
574 of block devices after services that synthesize these block
575 devices. In particular, this is intended to be used with storage
576 services (such as systemd-cryptsetup@.service(5)/ systemd-
577 veritysetup@.service(5)) that allocate and manage a virtual block
578 device. Storage services are ordered before an instance of
579 blockdev@.target, and the consumer units after it. The ordering is
580 particularly relevant during shutdown, as it ensures that the mount
581 is deactivated first and the service backing the mount later. The
582 blockdev@.target instance should be pulled in via a Wants=
583 dependency of the storage daemon and thus generally not be part of
584 any transaction unless a storage daemon is used. The instance name
585 for instances of this template unit must be a properly escaped
586 block device node path, e.g. blockdev@dev-mapper-foobar.target for
587 the storage device /dev/mapper/foobar.
588 cryptsetup-pre.target
590 This passive target unit may be pulled in by services that want to
591 run before any encrypted block device is set up. All encrypted
592 block devices are set up after this target has been reached. Since
593 the shutdown order is implicitly the reverse start-up order between
594 units, this target is particularly useful to ensure that a service
595 is shut down only after all encrypted block devices are fully
596 stopped.
597 veritysetup-pre.target
599 This passive target unit may be pulled in by services that want to
600 run before any verity integrity protected block device is set up.
601 All verity integrity protected block devices are set up after this
602 target has been reached. Since the shutdown order is implicitly the
603 reverse start-up order between units, this target is particularly
604 useful to ensure that a service is shut down only after all verity
605 integrity protected block devices are fully stopped.
606 first-boot-complete.target
608 This passive target is intended as a synchronization point for
609 units that need to run once during the first boot. Only after all
610 units ordered before this target have finished, will the machine-
611 id(5) be committed to disk, marking the first boot as completed. If
612 the boot is aborted at any time before that, the next boot will
613 re-run any units with ConditionFirstBoot=yes.
614 getty-pre.target
616 A special passive target unit. Users of this target are expected to
617 pull it in the boot transaction via a dependency (e.g. Wants=).
618 Order your unit before this unit if you want to make use of the
619 console just before getty is started.
620 local-fs-pre.target
622 This target unit is automatically ordered before all local mount
623 points marked with auto (see above). It can be used to execute
624 certain units before all local mounts.
625 network.target
627 This unit is supposed to indicate when network functionality is
628 available, but it is only very weakly defined what that is supposed
629 to mean. However, the following should apply at minimum:
630 • At start-up, any configured synthetic network devices (i.e. not
632 physical ones that require hardware to show up and be probed,
633 but virtual ones like bridge devices and similar which are
634 created programmatically) that do not depend on any underlying
635 hardware should be allocated by the time this target is
636 reached. It is not necessary for these interfaces to also have
637 completed IP level configuration by the time network.target is
638 reached.
639 • At shutdown, a unit that is ordered after network.target will
641 be stopped before the network — to whatever level it might be
642 set up by then — is shut down. It is hence useful when writing
643 service files that require network access on shutdown, which
644 should order themselves after this target, but not pull it in.
645 Also see Running Services After the Network Is Up[1] for more
646 information.
647 It must emphasized that at start-up there's no guarantee that
649 hardware-based devices have shown up by the time this target is
650 reached, or even acquired complete IP configuration. For that
651 purpose use network-online.target as described above.
652 network-pre.target
654 This passive target unit may be pulled in by services that want to
655 run before any network is set up, for example for the purpose of
656 setting up a firewall. All network management software orders
657 itself after this target, but does not pull it in. Also see Running
658 Services After the Network Is Up[1] for more information.
659 nss-lookup.target
661 A target that should be used as synchronization point for all
662 host/network name service lookups. Note that this is independent of
663 UNIX user/group name lookups for which nss-user-lookup.target
664 should be used. All services for which the availability of full
665 host/network name resolution is essential should be ordered after
666 this target, but not pull it in. systemd automatically adds
667 dependencies of type After= for this target unit to all SysV init
668 script service units with an LSB header referring to the "$named"
669 facility.
670 nss-user-lookup.target
672 A target that should be used as synchronization point for all
673 regular UNIX user/group name service lookups. Note that this is
674 independent of host/network name lookups for which
675 nss-lookup.target should be used. All services for which the
676 availability of the full user/group database is essential should be
677 ordered after this target, but not pull it in. All services which
678 provide parts of the user/group database should be ordered before
679 this target, and pull it in. Note that this unit is only relevant
680 for regular users and groups — system users and groups are required
681 to be resolvable during earliest boot already, and hence do not
682 need any special ordering against this target.
683 remote-fs-pre.target
685 This target unit is automatically ordered before all mount point
686 units (see above) and cryptsetup/veritysetup devices marked with
687 the _netdev. It can be used to run certain units before remote
688 encrypted devices and mounts are established. Note that this unit
689 is generally not part of the initial transaction, unless the unit
690 that wants to be ordered before all remote mounts pulls it in via a
691 Wants= type dependency. If the unit wants to be pulled in by the
692 first remote mount showing up, it should use network-online.target
693 (see above).
694 rpcbind.target
696 The portmapper/rpcbind pulls in this target and orders itself
697 before it, to indicate its availability. systemd automatically adds
698 dependencies of type After= for this target unit to all SysV init
699 script service units with an LSB header referring to the "$portmap"
700 facility.
701 time-set.target
703 Services responsible for setting the system clock (CLOCK_REALTIME)
704 from a local source (such as a maintained timestamp file or
705 imprecise real-time clock) should pull in this target and order
706 themselves before it. Services where approximate, roughly monotonic
707 time is desired should be ordered after this unit, but not pull it
708 in.
709 This target does not provide the accuracy guarantees of
711 time-sync.target (see below), however does not depend on remote
712 clock sources to be reachable, i.e. the target is typically not
713 delayed by network problems and similar. Use of this target is
714 recommended for services where approximate clock accuracy and rough
715 monotonicity is desired but activation shall not be delayed for
716 possibly unreliable network communication.
717 The service manager automatically adds dependencies of type After=
719 for this target unit to all timer units with at least one
720 OnCalendar= directive.
721 The systemd-timesyncd.service(8) service is a simple daemon that
723 pulls in this target and orders itself before it. Besides
724 implementing the SNTP network protocol it maintains a timestamp
725 file on disk whose modification time is regularly updated. At
726 service start-up the local system clock is set from that
727 modification time, ensuring it increases roughly monotonically.
728 Note that ordering a unit after time-set.target only has effect if
730 there's actually a service ordered before it that delays it until
731 the clock is adjusted for rough monotonicity. Otherwise, this
732 target might get reached before the clock is adjusted to be roughly
733 monotonic. Enable systemd-timesyncd.service(8), or an alternative
734 NTP implementation to delay the target.
735 time-sync.target
737 Services indicating completed synchronization of the system clock
738 (CLOCK_REALTIME) to a remote source should pull in this target and
739 order themselves before it. Services where accurate time is
740 essential should be ordered after this unit, but not pull it in.
741 The service manager automatically adds dependencies of type After=
743 for this target unit to all SysV init script service units with an
744 LSB header referring to the "$time" facility, as well to all timer
745 units with at least one OnCalendar= directive.
746 This target provides stricter clock accuracy guarantees than
748 time-set.target (see above), but likely requires network
749 communication and thus introduces unpredictable delays. Services
750 that require clock accuracy and where network communication delays
751 are acceptable should use this target. Services that require a less
752 accurate clock, and only approximate and roughly monotonic clock
753 behaviour should use time-set.target instead.
754 Note that ordering a unit after time-sync.target only has effect if
756 there's actually a service ordered before it that delays it until
757 clock synchronization is reached. Otherwise, this target might get
758 reached before the clock is synchronized to any remote accurate
759 reference clock. When using systemd-timesyncd.service(8), enable
760 systemd-time-wait-sync.service(8) to delay the target; or use an
761 equivalent service for other NTP implementations.
762 Table 1. Comparison
764 ┌───────────────────────────┬────────────────────────────────┐
765 │time-set.target │ time-sync.target │
766 ├───────────────────────────┼────────────────────────────────┤
767 │"quick" to reach │ "slow" to reach │
768 ├───────────────────────────┼────────────────────────────────┤
769 │typically uses local clock │ typically uses remote │
770 │sources, boot process not │ clock sources, inserts │
771 │affected by availability │ dependencies on remote │
772 │of external resources │ resources into boot │
773 │ │ process │
774 ├───────────────────────────┼────────────────────────────────┤
775 │reliable, because local │ unreliable, because │
776 │ │ typically network involved │
777 ├───────────────────────────┼────────────────────────────────┤
778 │typically guarantees an │ typically guarantees an │
779 │approximate and roughly │ accurate clock │
780 │monotonic clock only │ │
781 ├───────────────────────────┼────────────────────────────────┤
782 │implemented by │ implemented by │
783 │systemd-timesyncd.service │ systemd-time-wait-sync.service │
784 └───────────────────────────┴────────────────────────────────┘
785 Special Slice Units
787 There are four ".slice" units which form the basis of the hierarchy for
788 assignment of resources for services, users, and virtual machines or
789 containers. See systemd.slice(7) for details about slice units.
790 -.slice
792 The root slice is the root of the slice hierarchy. It usually does
793 not contain units directly, but may be used to set defaults for the
794 whole tree.
795 system.slice
797 By default, all system services started by systemd are found in
798 this slice.
799 user.slice
801 By default, all user processes and services started on behalf of
802 the user, including the per-user systemd instance are found in this
803 slice. This is pulled in by systemd-logind.service.
804 machine.slice
806 By default, all virtual machines and containers registered with
807 systemd-machined are found in this slice. This is pulled in by
808 systemd-machined.service.
809
811 Special User Units
812 When systemd runs as a user instance, the following special units are
813 available:
814 default.target
816 This is the main target of the user session, started by default.
817 Various services that compose the normal user session should be
818 pulled into this target. In this regard, default.target is similar
819 to multi-user.target in the system instance, but it is a real unit,
820 not an alias.
821 In addition, the following units are available which have definitions
823 similar to their system counterparts: exit.target, shutdown.target,
824 sockets.target, timers.target, paths.target, bluetooth.target,
825 printer.target, smartcard.target, sound.target.
826 Special Passive User Units
828 graphical-session.target
829 This target is active whenever any graphical session is running. It
830 is used to stop user services which only apply to a graphical (X,
831 Wayland, etc.) session when the session is terminated. Such
832 services should have "PartOf=graphical-session.target" in their
833 [Unit] section. A target for a particular session (e. g.
834 gnome-session.target) starts and stops "graphical-session.target"
835 with "BindsTo=graphical-session.target".
836 Which services are started by a session target is determined by the
838 "Wants=" and "Requires=" dependencies. For services that can be
839 enabled independently, symlinks in ".wants/" and ".requires/"
840 should be used, see systemd.unit(5). Those symlinks should either
841 be shipped in packages, or should be added dynamically after
842 installation, for example using "systemctl add-wants", see
843 systemctl(1).
844 Example 1. Nautilus as part of a GNOME session
846 "gnome-session.target" pulls in Nautilus as top-level service:
847 [Unit]
849 Description=User systemd services for GNOME graphical session
850 Wants=nautilus.service
851 BindsTo=graphical-session.target
852 "nautilus.service" gets stopped when the session stops:
854 [Unit]
856 Description=Render the desktop icons with Nautilus
857 PartOf=graphical-session.target
858 [Service]
860 ...
861 graphical-session-pre.target
863 This target contains services which set up the environment or
864 global configuration of a graphical session, such as SSH/GPG agents
865 (which need to export an environment variable into all desktop
866 processes) or migration of obsolete d-conf keys after an OS upgrade
867 (which needs to happen before starting any process that might use
868 them). This target must be started before starting a graphical
869 session like gnome-session.target.
870 xdg-desktop-autostart.target
872 The XDG specification defines a way to autostart applications using
873 XDG desktop files. systemd ships systemd-xdg-autostart-generator(8)
874 for the XDG desktop files in autostart directories. Desktop
875 Environments can opt-in to use this service by adding a Wants=
876 dependency on xdg-desktop-autostart.target.
877 Special User Slice Units
879 There are four ".slice" units which form the basis of the user
880 hierarchy for assignment of resources for user applications and
881 services. See systemd.slice(7) for details about slice units and the
882 documentation about Desktop Environments[3] for further information.
883 -.slice
885 The root slice is the root of the user's slice hierarchy. It
886 usually does not contain units directly, but may be used to set
887 defaults for the whole tree.
888 app.slice
890 By default, all user services and applications managed by systemd
891 are found in this slice. All interactively launched applications
892 like web browsers and text editors as well as non-critical services
893 should be placed into this slice.
894 session.slice
896 All essential services and applications required for the session
897 should use this slice. These are services that either cannot be
898 restarted easily or where latency issues may affect the
899 interactivity of the system and applications. This includes the
900 display server, screen readers and other services such as DBus or
901 XDG portals. Such services should be configured to be part of this
902 slice by adding Slice=session.slice to their unit files.
903 background.slice
905 All services running low-priority background tasks should use this
906 slice. This permits resources to be preferentially assigned to the
907 other slices. Examples include non-interactive tasks like file
908 indexing or backup operations where latency is not important.
909
911 systemd(1), systemd.unit(5), systemd.service(5), systemd.socket(5),
912 systemd.target(5), systemd.slice(5), bootup(7), systemd-fstab-
913 generator(8), user@.service(5)
914
916 1. Running Services After the Network Is Up
917 https://systemd.io/NETWORK_ONLINE
918 2. Syslog Interface
920 https://www.freedesktop.org/wiki/Software/systemd/syslog
921 3. Desktop Environments
923 https://systemd.io/DESKTOP_ENVIRONMENTS
924systemd 254 SYSTEMD.SPECIAL(7)