{ "mode": "man", "parameter": "systemd.special", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/systemd.special/7/json", "generated": "2026-06-15T14:38:08Z", "synopsis": "basic.target, bluetooth.target, cryptsetup-pre.target, cryptsetup.target,\nveritysetup-pre.target, veritysetup.target, ctrl-alt-del.target, blockdev@.target,\nboot-complete.target, default.target, emergency.target, exit.target, final.target,\nfirst-boot-complete.target, getty.target, getty-pre.target, graphical.target, halt.target,\nhibernate.target, hybrid-sleep.target, suspend-then-hibernate.target, initrd.target,\ninitrd-fs.target, initrd-root-device.target, initrd-root-fs.target, initrd-usr-fs.target,\nkbrequest.target, kexec.target, local-fs-pre.target, local-fs.target, machines.target\nmulti-user.target, network-online.target, network-pre.target, network.target,\nnss-lookup.target, nss-user-lookup.target, paths.target, poweroff.target, printer.target,\nreboot.target, remote-cryptsetup.target, remote-veritysetup.target, remote-fs-pre.target,\nremote-fs.target, rescue.target, rpcbind.target, runlevel2.target, runlevel3.target,\nrunlevel4.target, runlevel5.target, shutdown.target, sigpwr.target, sleep.target,\nslices.target, smartcard.target, sockets.target, sound.target, suspend.target, swap.target,\nsysinit.target, system-update.target, system-update-pre.target, time-set.target,\ntime-sync.target, timers.target, umount.target, usb-gadget.target, -.slice, system.slice,\nuser.slice, machine.slice, -.mount, dbus.service, dbus.socket, display-manager.service,\ninit.scope, syslog.socket, system-update-cleanup.service", "sections": { "NAME": { "content": "systemd.special - Special systemd units\n", "subsections": [] }, "SYNOPSIS": { "content": "basic.target, bluetooth.target, cryptsetup-pre.target, cryptsetup.target,\nveritysetup-pre.target, veritysetup.target, ctrl-alt-del.target, blockdev@.target,\nboot-complete.target, default.target, emergency.target, exit.target, final.target,\nfirst-boot-complete.target, getty.target, getty-pre.target, graphical.target, halt.target,\nhibernate.target, hybrid-sleep.target, suspend-then-hibernate.target, initrd.target,\ninitrd-fs.target, initrd-root-device.target, initrd-root-fs.target, initrd-usr-fs.target,\nkbrequest.target, kexec.target, local-fs-pre.target, local-fs.target, machines.target\nmulti-user.target, network-online.target, network-pre.target, network.target,\nnss-lookup.target, nss-user-lookup.target, paths.target, poweroff.target, printer.target,\nreboot.target, remote-cryptsetup.target, remote-veritysetup.target, remote-fs-pre.target,\nremote-fs.target, rescue.target, rpcbind.target, runlevel2.target, runlevel3.target,\nrunlevel4.target, runlevel5.target, shutdown.target, sigpwr.target, sleep.target,\nslices.target, smartcard.target, sockets.target, sound.target, suspend.target, swap.target,\nsysinit.target, system-update.target, system-update-pre.target, time-set.target,\ntime-sync.target, timers.target, umount.target, usb-gadget.target, -.slice, system.slice,\nuser.slice, machine.slice, -.mount, dbus.service, dbus.socket, display-manager.service,\ninit.scope, syslog.socket, system-update-cleanup.service\n", "subsections": [] }, "DESCRIPTION": { "content": "A few units are treated specially by systemd. Many of them have special internal semantics\nand cannot be renamed, while others simply have a standard meaning and should be present on\nall systems.\n", "subsections": [] }, "UNITS MANAGED BY THE SYSTEM SERVICE MANAGER": { "content": "", "subsections": [ { "name": "Special System Units", "content": "-.mount\nThe root mount point, i.e. the mount unit for the / path. This unit is unconditionally\nactive, during the entire time the system is up, as this mount point is where the basic\nuserspace is running from.\n\nbasic.target\nA special target unit covering basic boot-up.\n\nsystemd automatically adds dependency of the type After= for this target unit to all\nservices (except for those with DefaultDependencies=no).\n\nUsually, this should pull-in all local mount points plus /var/, /tmp/ and /var/tmp/, swap\ndevices, sockets, timers, path units and other basic initialization necessary for general\npurpose daemons. The mentioned mount points are special cased to allow them to be remote.\n\nThis target usually does not pull in any non-target units directly, but rather does so\nindirectly via other early boot targets. It is instead meant as a synchronization point\nfor late boot services. Refer to bootup(7) for details on the targets involved.\n\nboot-complete.target\nThis target is intended as generic synchronization point for services that shall\ndetermine or act on whether the boot process completed successfully. Order units that are\nrequired to succeed for a boot process to be considered successful before this unit, and\nadd a Requires= dependency from the target unit to them. Order units that shall only run\nwhen the boot process is considered successful after the target unit and pull in the\ntarget from it, also with Requires=. Note that by default this target unit is not part of\nthe initial boot transaction, but is supposed to be pulled in only if required by units\nthat want to run only on successful boots.\n\nSee systemd-boot-check-no-failures.service(8) for a service that implements a generic\nsystem health check and orders itself before boot-complete.target.\n\nSee systemd-bless-boot.service(8) for a service that propagates boot success information\nto the boot loader, and orders itself after boot-complete.target.\n\nctrl-alt-del.target\nsystemd starts this target whenever Control+Alt+Del is pressed on the console. Usually,\nthis should be aliased (symlinked) to reboot.target.\n\ncryptsetup.target\nA target that pulls in setup services for all encrypted block devices.\n\nveritysetup.target\nA target that pulls in setup services for all verity integrity protected block devices.\n\ndbus.service\nA special unit for the D-Bus bus daemon. As soon as this service is fully started up\nsystemd will connect to it and register its service.\n\ndbus.socket\nA special unit for the D-Bus system bus socket. All units with Type=dbus automatically\ngain a dependency on this unit.\n\ndefault.target\nThe default unit systemd starts at bootup. Usually, this should be aliased (symlinked) to\nmulti-user.target or graphical.target. See bootup(7) for more discussion.\n\nThe default unit systemd starts at bootup can be overridden with the systemd.unit= kernel\ncommand line option, or more conveniently, with the short names like single, rescue, 1,\n3, 5, ...; see systemd(1).\n\ndisplay-manager.service\nThe display manager service. Usually, this should be aliased (symlinked) to gdm.service\nor a similar display manager service.\n\nemergency.target\nA special target unit that starts an emergency shell on the main console. This target\ndoes not pull in other services or mounts. It is the most minimal version of starting the\nsystem in order to acquire an interactive shell; the only processes running are usually\njust the system manager (PID 1) and the shell process. This unit may be used by\nspecifying emergency on the kernel command line; it is also used when a file system check\non a required file system fails and boot-up cannot continue. Compare with rescue.target,\nwhich serves a similar purpose, but also starts the most basic services and mounts all\nfile systems.\n\nIn many ways booting into emergency.target is similar to the effect of booting with\n\"init=/bin/sh\" on the kernel command line, except that emergency mode provides you with\nthe full system and service manager, and allows starting individual units in order to\ncontinue the boot process in steps.\n\nNote that depending on how emergency.target is reached, the root file system might be\nmounted read-only or read-write (no remounting is done specially for this target). For\nexample, the system may boot with root mounted read-only when ro is used on the kernel\ncommand line and remain this way for emergency.target, or the system may transition to\nemergency.target after the system has been partially booted and disks have already been\nremounted read-write.\n\nexit.target\nA special service unit for shutting down the system or user service manager. It is\nequivalent to poweroff.target on non-container systems, and also works in containers.\n\nsystemd will start this unit when it receives the SIGTERM or SIGINT signal when running\nas user service daemon.\n\nNormally, this (indirectly) pulls in shutdown.target, which in turn should be conflicted\nby all units that want to be scheduled for shutdown when the service manager starts to\nexit.\n\nfinal.target\nA special target unit that is used during the shutdown logic and may be used to pull in\nlate services after all normal services are already terminated and all mounts unmounted.\n\ngetty.target\nA special target unit that pulls in statically configured local TTY getty instances.\n\ngraphical.target\nA special target unit for setting up a graphical login screen. This pulls in\nmulti-user.target.\n\nUnits that are needed for graphical logins shall add Wants= dependencies for their unit\nto this unit (or multi-user.target) during installation. This is best configured via\nWantedBy=graphical.target in the unit's [Install] section.\n\nhibernate.target\nA special target unit for hibernating the system. This pulls in sleep.target.\n\nhybrid-sleep.target\nA special target unit for hibernating and suspending the system at the same time. This\npulls in sleep.target.\n\nsuspend-then-hibernate.target\nA special target unit for suspending the system for a period of time, waking it and\nputting it into hibernate. This pulls in sleep.target.\n\nhalt.target\nA special target unit for shutting down and halting the system. Note that this target is\ndistinct from poweroff.target in that it generally really just halts the system rather\nthan powering it down.\n\nApplications wanting to halt the system should not start this unit directly, but should\ninstead execute systemctl halt (possibly with the --no-block option) or call systemd(1)'s\norg.freedesktop.systemd1.Manager.Halt D-Bus method directly.\n\ninit.scope\nThis scope unit is where the system and service manager (PID 1) itself resides. It is\nactive as long as the system is running.\n\ninitrd.target\nThis is the default target in the initramfs, similar to default.target in the main\nsystem. It is used to mount the real root and transition to it. See bootup(7) for more\ndiscussion.\n\ninitrd-fs.target\nsystemd-fstab-generator(3) automatically adds dependencies of type Before= to\nsysroot-usr.mount and all mount points found in /etc/fstab that have the x-initrd.mount\nmount option set and do not have the noauto mount option set. It is also indirectly\nordered after sysroot.mount. Thus, once this target is reached the /sysroot/ hierarchy is\nfully set up, in preparation for the transition to the host OS.\n\ninitrd-root-device.target\nA special initrd target unit that is reached when the root filesystem device is\navailable, but before it has been mounted. systemd-fstab-generator(3) and systemd-gpt-\nauto-generator(3) automatically setup the appropriate dependencies to make this happen.\n\ninitrd-root-fs.target\nsystemd-fstab-generator(3) automatically adds dependencies of type Before= to the\nsysroot.mount unit, which is generated from the kernel command line's root= setting (or\nequivalent).\n\ninitrd-usr-fs.target\nsystemd-fstab-generator(3) automatically adds dependencies of type Before= to the\nsysusr-usr.mount unit, which is generated from the kernel command line's usr= switch.\nServices may order themselves after this target unit in order to run once the /sysusr/\nhierarchy becomes available, on systems that come up initially without a root file\nsystem, but with an initialized /usr/ and need to access that before setting up the root\nfile system to ultimately switch to. On systems where usr= is not used this target is\nordered after sysroot.mount and thus mostly equivalent to initrd-root-fs.target. In\neffect on any system once this target is reached the file system backing /usr/ is\nmounted, though possibly at two different locations, either below the /sysusr/ or the\n/sysroot/ hierarchies.\n\nkbrequest.target\nsystemd starts this target whenever Alt+ArrowUp is pressed on the console. Note that any\nuser with physical access to the machine will be able to do this, without authentication,\nso this should be used carefully.\n\nkexec.target\nA special target unit for shutting down and rebooting the system via kexec.\n\nApplications wanting to reboot the system should not start this unit directly, but should\ninstead execute systemctl kexec (possibly with the --no-block option) or call\nsystemd(1)'s org.freedesktop.systemd1.Manager.KExec D-Bus method directly.\n\nlocal-fs.target\nsystemd-fstab-generator(3) automatically adds dependencies of type Before= to all mount\nunits that refer to local mount points for this target unit. In addition, it adds\ndependencies of type Wants= to this target unit for those mounts listed in /etc/fstab\nthat have the auto mount option set.\n\nmachines.target\nA standard target unit for starting all the containers and other virtual machines. See\nsystemd-nspawn@.service for an example.\n\nmulti-user.target\nA special target unit for setting up a multi-user system (non-graphical). This is pulled\nin by graphical.target.\n\nUnits that are needed for a multi-user system shall add Wants= dependencies for their\nunit to this unit during installation. This is best configured via\nWantedBy=multi-user.target in the unit's [Install] section.\n\nnetwork-online.target\nUnits that strictly require a configured network connection should pull in\nnetwork-online.target (via a Wants= type dependency) and order themselves after it. This\ntarget unit is intended to pull in a service that delays further execution until the\nnetwork is sufficiently set up. What precisely this requires is left to the\nimplementation of the network managing service.\n\nNote the distinction between this unit and network.target. This unit is an active unit\n(i.e. pulled in by the consumer rather than the provider of this functionality) and pulls\nin a service which possibly adds substantial delays to further execution. In contrast,\nnetwork.target is a passive unit (i.e. pulled in by the provider of the functionality,\nrather than the consumer) that usually does not delay execution much. Usually,\nnetwork.target is part of the boot of most systems, while network-online.target is not,\nexcept when at least one unit requires it. Also see Running Services After the Network is\nup[1] for more information.\n\nAll mount units for remote network file systems automatically pull in this unit, and\norder themselves after it. Note that networking daemons that simply provide functionality\nto other hosts (as opposed to consume functionality of other hosts) generally do not need\nto pull this in.\n\nsystemd automatically adds dependencies of type Wants= and After= for this target unit to\nall SysV init script service units with an LSB header referring to the \"$network\"\nfacility.\n\nNote that this unit is only useful during the original system start-up logic. After the\nsystem has completed booting up, it will not track the online state of the system\nanymore. Due to this it cannot be used as a network connection monitor concept, it is\npurely a one-time system start-up concept.\n\npaths.target\nA special target unit that sets up all path units (see systemd.path(5) for details) that\nshall be active after boot.\n\nIt is recommended that path units installed by applications get pulled in via Wants=\ndependencies from this unit. This is best configured via a WantedBy=paths.target in the\npath unit's [Install] section.\n\npoweroff.target\nA special target unit for shutting down and powering off the system.\n\nApplications wanting to power off the system should not start this unit directly, but\nshould instead execute systemctl poweroff (possibly with the --no-block option) or call\nsystemd-logind(8)'s org.freedesktop.login1.Manager.PowerOff D-Bus method directly.\n\nrunlevel0.target is an alias for this target unit, for compatibility with SysV.\n\nreboot.target\nA special target unit for shutting down and rebooting the system.\n\nApplications wanting to reboot the system should not start this unit directly, but should\ninstead execute systemctl reboot (possibly with the --no-block option) or call systemd-\nlogind(8)'s org.freedesktop.login1.Manager.Reboot D-Bus method directly.\n\nrunlevel6.target is an alias for this target unit, for compatibility with SysV.\n\nremote-cryptsetup.target\nSimilar to cryptsetup.target, but for encrypted devices which are accessed over the\nnetwork. It is used for crypttab(8) entries marked with netdev.\n\nremote-veritysetup.target\nSimilar to veritysetup.target, but for verity integrity protected devices which are\naccessed over the network. It is used for veritytab(8) entries marked with netdev.\n\nremote-fs.target\nSimilar to local-fs.target, but for remote mount points.\n\nsystemd automatically adds dependencies of type After= for this target unit to all SysV\ninit script service units with an LSB header referring to the \"$remotefs\" facility.\n\nrescue.target\nA special target unit that pulls in the base system (including system mounts) and spawns\na rescue shell. Isolate to this target in order to administer the system in single-user\nmode with all file systems mounted but with no services running, except for the most\nbasic. Compare with emergency.target, which is much more reduced and does not provide the\nfile systems or most basic services. Compare with multi-user.target, this target could be\nseen as single-user.target.\n\nrunlevel1.target is an alias for this target unit, for compatibility with SysV.\n\nUse the \"systemd.unit=rescue.target\" kernel command line option to boot into this mode. A\nshort alias for this kernel command line option is \"1\", for compatibility with SysV.\n\nrunlevel2.target, runlevel3.target, runlevel4.target, runlevel5.target\nThese are targets that are called whenever the SysV compatibility code asks for runlevel\n2, 3, 4, 5, respectively. It is a good idea to make this an alias for (i.e. symlink to)\ngraphical.target (for runlevel 5) or multi-user.target (the others).\n\nshutdown.target\nA special target unit that terminates the services on system shutdown.\n\nServices that shall be terminated on system shutdown shall add Conflicts= and Before=\ndependencies to this unit for their service unit, which is implicitly done when\nDefaultDependencies=yes is set (the default).\n\nsigpwr.target\nA special target that is started when systemd receives the SIGPWR process signal, which\nis normally sent by the kernel or UPS daemons when power fails.\n\nsleep.target\nA special target unit that is pulled in by suspend.target, hibernate.target and\nhybrid-sleep.target and may be used to hook units into the sleep state logic.\n\nslices.target\nA special target unit that sets up all slice units (see systemd.slice(5) for details)\nthat shall always be active after boot. By default the generic system.slice slice unit as\nwell as the root slice unit -.slice are pulled in and ordered before this unit (see\nbelow).\n\nAdding slice units to slices.target is generally not necessary. Instead, when some unit\nthat uses Slice= is started, the specified slice will be started automatically. Adding\nWantedBy=slices.target lines to the [Install] section should only be done for units that\nneed to be always active. In that case care needs to be taken to avoid creating a loop\nthrough the automatic dependencies on \"parent\" slices.\n\nsockets.target\nA special target unit that sets up all socket units (see systemd.socket(5) for details)\nthat shall be active after boot.\n\nServices that can be socket-activated shall add Wants= dependencies to this unit for\ntheir socket unit during installation. This is best configured via a\nWantedBy=sockets.target in the socket unit's [Install] section.\n\nsuspend.target\nA special target unit for suspending the system. This pulls in sleep.target.\n\nswap.target\nSimilar to local-fs.target, but for swap partitions and swap files.\n\nsysinit.target\nsystemd automatically adds dependencies of the types Requires= and After= for this target\nunit to all services (except for those with DefaultDependencies=no).\n\nThis target pulls in the services required for system initialization. System services\npulled in by this target should declare DefaultDependencies=no and specify all their\ndependencies manually, including access to anything more than a read only root\nfilesystem. For details on the dependencies of this target, refer to bootup(7).\n\nsyslog.socket\nThe socket unit syslog implementations should listen on. All userspace log messages will\nbe made available on this socket. For more information about syslog integration, please\nconsult the Syslog Interface[2] document.\n\nsystem-update.target, system-update-pre.target, system-update-cleanup.service\nA special target unit that is used for offline system updates. systemd-system-update-\ngenerator(8) will redirect the boot process to this target if /system-update exists. For\nmore information see systemd.offline-updates(7).\n\nUpdates should happen before the system-update.target is reached, and the services which\nimplement them should cause the machine to reboot. The main units executing the update\nshould order themselves after system-update-pre.target but not pull it in. Services which\nwant to run during system updates only, but before the actual system update is executed\nshould order themselves before this unit and pull it in. As a safety measure, if this\ndoes not happen, and /system-update still exists after system-update.target is reached,\nsystem-update-cleanup.service will remove this symlink and reboot the machine.\n\ntimers.target\nA special target unit that sets up all timer units (see systemd.timer(5) for details)\nthat shall be active after boot.\n\nIt is recommended that timer units installed by applications get pulled in via Wants=\ndependencies from this unit. This is best configured via WantedBy=timers.target in the\ntimer unit's [Install] section.\n\numount.target\nA special target unit that unmounts all mount and automount points on system shutdown.\n\nMounts that shall be unmounted on system shutdown shall add Conflicts dependencies to\nthis unit for their mount unit, which is implicitly done when DefaultDependencies=yes is\nset (the default).\n" }, { "name": "Special System Units for Devices", "content": "Some target units are automatically pulled in as devices of certain kinds show up in the\nsystem. These may be used to automatically activate various services based on the specific\ntype of the available hardware.\n\nbluetooth.target\nThis target is started automatically as soon as a Bluetooth controller is plugged in or\nbecomes available at boot.\n\nThis may be used to pull in Bluetooth management daemons dynamically when Bluetooth\nhardware is found.\n\nprinter.target\nThis target is started automatically as soon as a printer is plugged in or becomes\navailable at boot.\n\nThis may be used to pull in printer management daemons dynamically when printer hardware\nis found.\n\nsmartcard.target\nThis target is started automatically as soon as a smartcard controller is plugged in or\nbecomes available at boot.\n\nThis may be used to pull in smartcard management daemons dynamically when smartcard\nhardware is found.\n\nsound.target\nThis target is started automatically as soon as a sound card is plugged in or becomes\navailable at boot.\n\nThis may be used to pull in audio management daemons dynamically when audio hardware is\nfound.\n\nusb-gadget.target\nThis target is started automatically as soon as a USB Device Controller becomes available\nat boot.\n\nThis may be used to pull in usb gadget dynamically when UDC hardware is found.\n" }, { "name": "Special Passive System Units", "content": "A number of special system targets are defined that can be used to properly order boot-up of\noptional services. These targets are generally not part of the initial boot transaction,\nunless they are explicitly pulled in by one of the implementing services. Note specifically\nthat these passive target units are generally not pulled in by the consumer of a service, but\nby the provider of the service. This means: a consuming service should order itself after\nthese targets (as appropriate), but not pull it in. A providing service should order itself\nbefore these targets (as appropriate) and pull it in (via a Wants= type dependency).\n\nNote that these passive units cannot be started manually, i.e. \"systemctl start\ntime-sync.target\" will fail with an error. They can only be pulled in by dependency. This is\nenforced since they exist for ordering purposes only and thus are not useful as only unit\nwithin a transaction.\n\nblockdev@.target\nThis template unit is used to order mount units and other consumers of block devices\nafter services that synthesize these block devices. In particular, this is intended to be\nused with storage services (such as systemd-cryptsetup@.service(5)/ systemd-\nveritysetup@.service(5)) that allocate and manage a virtual block device. Storage\nservices are ordered before an instance of blockdev@.target, and the consumer units after\nit. The ordering is particularly relevant during shutdown, as it ensures that the mount\nis deactivated first and the service backing the mount later. The blockdev@.target\ninstance should be pulled in via a Wants= dependency of the storage daemon and thus\ngenerally not be part of any transaction unless a storage daemon is used. The instance\nname for instances of this template unit must be a properly escaped block device node\npath, e.g. blockdev@dev-mapper-foobar.target for the storage device /dev/mapper/foobar.\n\ncryptsetup-pre.target\nThis passive target unit may be pulled in by services that want to run before any\nencrypted block device is set up. All encrypted block devices are set up after this\ntarget has been reached. Since the shutdown order is implicitly the reverse start-up\norder between units, this target is particularly useful to ensure that a service is shut\ndown only after all encrypted block devices are fully stopped.\n\nveritysetup-pre.target\nThis passive target unit may be pulled in by services that want to run before any verity\nintegrity protected block device is set up. All verity integrity protected block devices\nare set up after this target has been reached. Since the shutdown order is implicitly the\nreverse start-up order between units, this target is particularly useful to ensure that a\nservice is shut down only after all verity integrity protected block devices are fully\nstopped.\n\nfirst-boot-complete.target\nThis passive target is intended as a synchronization point for units that need to run\nonce during the first boot. Only after all units ordered before this target have\nfinished, will the machine-id(5) be committed to disk, marking the first boot as\ncompleted. If the boot is aborted at any time before that, the next boot will re-run any\nunits with ConditionFirstBoot=yes.\n\ngetty-pre.target\nA special passive target unit. Users of this target are expected to pull it in the boot\ntransaction via a dependency (e.g. Wants=). Order your unit before this unit if you want\nto make use of the console just before getty is started.\n\nlocal-fs-pre.target\nThis target unit is automatically ordered before all local mount points marked with auto\n(see above). It can be used to execute certain units before all local mounts.\n\nnetwork.target\nThis unit is supposed to indicate when network functionality is available, but it is only\nvery weakly defined what that is supposed to mean. However, the following should apply at\nminimum:\n\n• At start-up, any configured synthetic network devices (i.e. not physical ones that\nrequire hardware to show up and be probed, but virtual ones like bridge devices and\nsimilar which are created programmatically) that do not depend on any underlying\nhardware should be allocated by the time this target is reached. It is not necessary\nfor these interfaces to also have completed IP level configuration by the time\nnetwork.target is reached.\n\n• At shutdown, a unit that is ordered after network.target will be stopped before the\nnetwork — to whatever level it might be set up by then — is shut down. It is hence\nuseful when writing service files that require network access on shutdown, which\nshould order themselves after this target, but not pull it in. Also see Running\nServices After the Network is up[1] for more information.\n\nIt must emphasized that at start-up there's no guarantee that hardware-based devices have\nshown up by the time this target is reached, or even acquired complete IP configuration.\nFor that purpose use network-online.target as described above.\n\nnetwork-pre.target\nThis passive target unit may be pulled in by services that want to run before any network\nis set up, for example for the purpose of setting up a firewall. All network management\nsoftware orders itself after this target, but does not pull it in.\n\nnss-lookup.target\nA target that should be used as synchronization point for all host/network name service\nlookups. Note that this is independent of UNIX user/group name lookups for which\nnss-user-lookup.target should be used. All services for which the availability of full\nhost/network name resolution is essential should be ordered after this target, but not\npull it in. systemd automatically adds dependencies of type After= for this target unit\nto all SysV init script service units with an LSB header referring to the \"$named\"\nfacility.\n\nnss-user-lookup.target\nA target that should be used as synchronization point for all regular UNIX user/group\nname service lookups. Note that this is independent of host/network name lookups for\nwhich nss-lookup.target should be used. All services for which the availability of the\nfull user/group database is essential should be ordered after this target, but not pull\nit in. All services which provide parts of the user/group database should be ordered\nbefore this target, and pull it in. Note that this unit is only relevant for regular\nusers and groups — system users and groups are required to be resolvable during earliest\nboot already, and hence do not need any special ordering against this target.\n\nremote-fs-pre.target\nThis target unit is automatically ordered before all mount point units (see above) and\ncryptsetup/veritysetup devices marked with the netdev. It can be used to run certain\nunits before remote encrypted devices and mounts are established. Note that this unit is\ngenerally not part of the initial transaction, unless the unit that wants to be ordered\nbefore all remote mounts pulls it in via a Wants= type dependency. If the unit wants to\nbe pulled in by the first remote mount showing up, it should use network-online.target\n(see above).\n\nrpcbind.target\nThe portmapper/rpcbind pulls in this target and orders itself before it, to indicate its\navailability. systemd automatically adds dependencies of type After= for this target unit\nto all SysV init script service units with an LSB header referring to the \"$portmap\"\nfacility.\n\ntime-set.target\nServices responsible for setting the system clock (CLOCKREALTIME) from a local source\n(such as a maintained timestamp file or imprecise real-time clock) should pull in this\ntarget and order themselves before it. Services where approximate, roughly monotonic time\nis desired should be ordered after this unit, but not pull it in.\n\nThis target does not provide the accuracy guarantees of time-sync.target (see below),\nhowever does not depend on remote clock sources to be reachable, i.e. the target is\ntypically not delayed by network problems and similar. Use of this target is recommended\nfor services where approximate clock accuracy and rough monotonicity is desired but\nactivation shall not be delayed for possibly unreliable network communication.\n\nThe service manager automatically adds dependencies of type After= for this target unit\nto all timer units with at least one OnCalendar= directive.\n\nThe systemd-timesyncd.service(8) service is a simple daemon that pulls in this target and\norders itself before it. Besides implementing the SNTP network protocol it maintains a\ntimestamp file on disk whose modification time is regularlary updated. At service\nstart-up the local system clock is set from that modification time, ensuring it increases\nroughly monotonically.\n\nNote that ordering a unit after time-set.target only has effect if there's actually a\nservice ordered before it that delays it until the clock is adjusted for rough\nmonotonicity. Otherwise, this target might get reached before the clock is adjusted to be\nroughly monotonic. Enable systemd-timesyncd.service(8), or an alternative NTP\nimplementation to delay the target.\n\ntime-sync.target\nServices indicating completed synchronization of the system clock (CLOCKREALTIME) to a\nremote source should pull in this target and order themselves before it. Services where\naccurate time is essential should be ordered after this unit, but not pull it in.\n\nThe service manager automatically adds dependencies of type After= for this target unit\nto all SysV init script service units with an LSB header referring to the \"$time\"\nfacility, as well to all timer units with at least one OnCalendar= directive.\n\nThis target provides stricter clock accuracy guarantees than time-set.target (see above),\nbut likely requires network communication and thus introduces unpredictable delays.\nServices that require clock accuracy and where network communication delays are\nacceptable should use this target. Services that require a less accurate clock, and only\napproximate and roughly monotonic clock behaviour should use time-set.target instead.\n\nNote that ordering a unit after time-sync.target only has effect if there's actually a\nservice ordered before it that delays it until clock synchronization is reached.\nOtherwise, this target might get reached before the clock is synchronized to any remote\naccurate reference clock. When using systemd-timesyncd.service(8), enable systemd-time-\nwait-sync.service(8) to delay the target; or use an equivalent service for other NTP\nimplementations.\n\nTable 1. Comparison\n┌──────────────────────────────────┬──────────────────────────────────┐\n│time-set.target │ time-sync.target │\n├──────────────────────────────────┼──────────────────────────────────┤\n│\"quick\" to reach │ \"slow\" to reach │\n├──────────────────────────────────┼──────────────────────────────────┤\n│typically uses local clock │ typically uses remote clock │\n│sources, boot process not │ sources, inserts dependencies on │\n│affected by availability of │ remote resources into boot │\n│external resources │ process │\n├──────────────────────────────────┼──────────────────────────────────┤\n│reliable, because local │ unreliable, because typically │\n│ │ network involved │\n├──────────────────────────────────┼──────────────────────────────────┤\n│typically guarantees an │ typically guarantees an accurate │\n│approximate and roughly monotonic │ clock │\n│clock only │ │\n├──────────────────────────────────┼──────────────────────────────────┤\n│implemented by │ implemented by │\n│systemd-timesyncd.service │ systemd-time-wait-sync.service │\n└──────────────────────────────────┴──────────────────────────────────┘\n" }, { "name": "Special Slice Units", "content": "There are four \".slice\" units which form the basis of the hierarchy for assignment of\nresources for services, users, and virtual machines or containers. See systemd.slice(7) for\ndetails about slice units.\n\n-.slice\nThe root slice is the root of the slice hierarchy. It usually does not contain units\ndirectly, but may be used to set defaults for the whole tree.\n\nsystem.slice\nBy default, all system services started by systemd are found in this slice.\n\nuser.slice\nBy default, all user processes and services started on behalf of the user, including the\nper-user systemd instance are found in this slice. This is pulled in by\nsystemd-logind.service.\n\nmachine.slice\nBy default, all virtual machines and containers registered with systemd-machined are\nfound in this slice. This is pulled in by systemd-machined.service.\n" } ] }, "UNITS MANAGED BY THE USER SERVICE MANAGER": { "content": "", "subsections": [ { "name": "Special User Units", "content": "When systemd runs as a user instance, the following special units are available:\n\ndefault.target\nThis is the main target of the user session, started by default. Various services that\ncompose the normal user session should be pulled into this target. In this regard,\ndefault.target is similar to multi-user.target in the system instance, but it is a real\nunit, not an alias.\n\nIn addition, the following units are available which have definitions similar to their system\ncounterparts: exit.target, shutdown.target, sockets.target, timers.target, paths.target,\nbluetooth.target, printer.target, smartcard.target, sound.target.\n" }, { "name": "Special Passive User Units", "content": "graphical-session.target\nThis target is active whenever any graphical session is running. It is used to stop user\nservices which only apply to a graphical (X, Wayland, etc.) session when the session is\nterminated. Such services should have \"PartOf=graphical-session.target\" in their [Unit]\nsection. A target for a particular session (e. g. gnome-session.target) starts and stops\n\"graphical-session.target\" with \"BindsTo=graphical-session.target\".\n\nWhich services are started by a session target is determined by the \"Wants=\" and\n\"Requires=\" dependencies. For services that can be enabled independently, symlinks in\n\".wants/\" and \".requires/\" should be used, see systemd.unit(5). Those symlinks should\neither be shipped in packages, or should be added dynamically after installation, for\nexample using \"systemctl add-wants\", see systemctl(1).\n\nExample 1. Nautilus as part of a GNOME session \"gnome-session.target\" pulls in Nautilus\nas top-level service:\n\n[Unit]\nDescription=User systemd services for GNOME graphical session\nWants=nautilus.service\nBindsTo=graphical-session.target\n\n\"nautilus.service\" gets stopped when the session stops:\n\n[Unit]\nDescription=Render the desktop icons with Nautilus\nPartOf=graphical-session.target\n\n[Service]\n...\n\ngraphical-session-pre.target\nThis target contains services which set up the environment or global configuration of a\ngraphical session, such as SSH/GPG agents (which need to export an environment variable\ninto all desktop processes) or migration of obsolete d-conf keys after an OS upgrade\n(which needs to happen before starting any process that might use them). This target must\nbe started before starting a graphical session like gnome-session.target.\n\nxdg-desktop-autostart.target\nThe XDG specification defines a way to autostart applications using XDG desktop files.\nsystemd ships systemd-xdg-autostart-generator(8) for the XDG desktop files in autostart\ndirectories. Desktop Environments can opt-in to use this service by adding a Wants=\ndependency on xdg-desktop-autostart.target.\n" }, { "name": "Special User Slice Units", "content": "There are four \".slice\" units which form the basis of the user hierarchy for assignment of\nresources for user applications and services. See systemd.slice(7) for details about slice\nunits and the documentation about Desktop Environments[3] for further information.\n\n-.slice\nThe root slice is the root of the user's slice hierarchy. It usually does not contain\nunits directly, but may be used to set defaults for the whole tree.\n\napp.slice\nBy default, all user services and applications managed by systemd are found in this\nslice. All interactively launched applications like web browsers and text editors as well\nas non-critical services should be placed into this slice.\n\nsession.slice\nAll essential services and applications required for the session should use this slice.\nThese are services that either cannot be restarted easily or where latency issues may\naffect the interactivity of the system and applications. This includes the display\nserver, screen readers and other services such as DBus or XDG portals. Such services\nshould be configured to be part of this slice by adding Slice=session.slice to their unit\nfiles.\n\nbackground.slice\nAll services running low-priority background tasks should use this slice. This permits\nresources to be preferentially assigned to the other slices. Examples include\nnon-interactive tasks like file indexing or backup operations where latency is not\nimportant.\n" } ] }, "SEE ALSO": { "content": "systemd(1), systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.target(5),\nsystemd.slice(5), bootup(7), systemd-fstab-generator(8), user@.service(5)\n", "subsections": [] }, "NOTES": { "content": "1. Running Services After the Network is up\nhttps://www.freedesktop.org/wiki/Software/systemd/NetworkTarget\n\n2. Syslog Interface\nhttps://www.freedesktop.org/wiki/Software/systemd/syslog\n\n3. Desktop Environments\nhttps://systemd.io/DESKTOPENVIRONMENTS\n\n\n\nsystemd 249 SYSTEMD.SPECIAL(7)", "subsections": [] } }, "summary": "systemd.special - Special systemd units", "flags": [], "examples": [], "see_also": [ { "name": "systemd", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/systemd/1/json" }, { "name": "systemd.unit", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.unit/5/json" }, { "name": "systemd.service", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.service/5/json" }, { "name": "systemd.socket", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.socket/5/json" }, { "name": "systemd.target", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.target/5/json" }, { "name": "systemd.slice", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/systemd.slice/5/json" }, { "name": "bootup", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/bootup/7/json" }, { "name": "systemd-fstab-generator", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/systemd-fstab-generator/8/json" }, { "name": ".service", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/.service/5/json" } ] }