diff --git a/man/rules/meson.build b/man/rules/meson.build index 9673ef8886f..35bc1743d9f 100644 --- a/man/rules/meson.build +++ b/man/rules/meson.build @@ -842,6 +842,7 @@ manpages = [ ''], ['udev_new', '3', ['udev_ref', 'udev_unref'], ''], ['udevadm', '8', [], ''], + ['user@.service', '5', ['user-runtime-dir@.service'], ''], ['vconsole.conf', '5', [], 'ENABLE_VCONSOLE'] ] # Really, do not edit. diff --git a/man/systemd.special.xml b/man/systemd.special.xml index fb12805fff1..38006c6abd9 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -104,942 +104,965 @@ - Special System Units + Units managed by the system's service manager - - - -.mount - - The root mount point, i.e. the mount unit for the / path. This unit is - unconditionally active, during the entire time the system is up, as this mount point is where the basic - userspace is running from. - - + + Special System Units - - basic.target - - A special target unit covering basic boot-up. - - systemd automatically adds dependency of the type - After= for this target unit to all - services (except for those with - DefaultDependencies=no). - - Usually, this should pull-in all local mount points plus - /var, /tmp and - /var/tmp, swap devices, sockets, timers, - path units and other basic initialization necessary for general - purpose daemons. The mentioned mount points are special cased - to allow them to be remote. - - - This target usually does not pull in any non-target units - directly, but rather does so indirectly via other early boot targets. - It is instead meant as a synchronization point for late boot - services. Refer to - bootup7 - for details on the targets involved. - - - - - - ctrl-alt-del.target - - systemd starts this target whenever Control+Alt+Del is - pressed on the console. Usually, this should be aliased - (symlinked) to reboot.target. - - - - cryptsetup.target - - A target that pulls in setup services for all - encrypted block devices. - - - - dbus.service - - A special unit for the D-Bus bus daemon. As soon as - this service is fully started up systemd will connect to it - and register its service. - - - - dbus.socket - - A special unit for the D-Bus system bus socket. All - units with Type=dbus automatically gain a - dependency on this unit. - - - - default.target - - The default unit systemd starts at bootup. Usually, - this should be aliased (symlinked) to - multi-user.target or - graphical.target. - - The default unit systemd starts at bootup can be - overridden with the systemd.unit= kernel - command line option. - - - - display-manager.service - - The display manager service. Usually, this should be - aliased (symlinked) to gdm.service or a - similar display manager service. - - - - emergency.target - - A special target unit that starts an emergency shell on the main console. This target does not pull in - any services or mounts. It is the most minimal version of starting the system in order to acquire an - interactive shell; the only processes running are usually just the system manager (PID 1) and the shell - process. This unit is supposed to be used with the kernel command line option - systemd.unit=; it is also used when a file system check on a required file system fails, - and boot-up cannot continue. Compare with rescue.target, which serves a similar purpose, - but also starts the most basic services and mounts all file systems. - - Use the systemd.unit=emergency.target kernel command line option to boot into this - mode. A short alias for this kernel command line option is emergency, for compatibility - with SysV. - - In many ways booting into emergency.target is similar to the effect of booting - with init=/bin/sh on the kernel command line, except that emergency mode provides you with - the full system and service manager, and allows starting individual units in order to continue the boot - process in steps. - - - - exit.target - - A special service unit for shutting down the system or - user service manager. It is equivalent to - poweroff.target on non-container - systems, and also works in containers. - - systemd will start this unit when it receives the - SIGTERM or SIGINT - signal when running as user service daemon. - - Normally, this (indirectly) pulls in - shutdown.target, which in turn should be - conflicted by all units that want to be scheduled for - shutdown when the service manager starts to exit. - - - - final.target - - A special target unit that is used during the shutdown - logic and may be used to pull in late services after all - normal services are already terminated and all mounts - unmounted. - - - - - getty.target - - A special target unit that pulls in statically - configured local TTY getty instances. - - - - - graphical.target - - A special target unit for setting up a graphical login - screen. This pulls in - multi-user.target. - - Units that are needed for graphical logins shall add - Wants= dependencies for their unit to - this unit (or multi-user.target) during - installation. This is best configured via - WantedBy=graphical.target in the unit's - [Install] section. - - - - hibernate.target - - A special target unit for hibernating the system. This - pulls in sleep.target. - - - - hybrid-sleep.target - - A special target unit for hibernating and suspending - the system at the same time. This pulls in - sleep.target. - - - - suspend-then-hibernate.target - - A special target unit for suspending the system for a period - of time, waking it and putting it into hibernate. This pulls in - sleep.target. - - - - - halt.target - - A special target unit for shutting down and halting - the system. Note that this target is distinct from - poweroff.target in that it generally - really just halts the system rather than powering it - down. - - Applications wanting to halt the system should not start this unit - directly, but should instead execute systemctl halt - (possibly with the option) or call - systemd1's - org.freedesktop.systemd1.Manager.Halt D-Bus method - directly. - - - - init.scope - - This scope unit is where the system and service manager (PID 1) itself resides. It is active as long as - the system is running. - - - - initrd-fs.target - - systemd-fstab-generator3 - automatically adds dependencies of type - Before= to - sysroot-usr.mount and all mount points - found in /etc/fstab that have - and not have - mount options set. - - - - initrd-root-device.target - - A special initrd target unit that is reached when the root filesystem device is available, but before - it has been mounted. - systemd-fstab-generator3 - and - systemd-gpt-auto-generator3 - automatically setup the appropriate dependencies to make this happen. - - - - - initrd-root-fs.target - - systemd-fstab-generator3 - automatically adds dependencies of type - Before= to the - sysroot.mount unit, which is generated - from the kernel command line. - - - - - kbrequest.target - - systemd starts this target whenever Alt+ArrowUp is - pressed on the console. Note that any user with physical access - to the machine will be able to do this, without authentication, - so this should be used carefully. - - - - kexec.target - - A special target unit for shutting down and rebooting - the system via kexec. - - Applications wanting to reboot the system should not start this unit - directly, but should instead execute systemctl kexec - (possibly with the option) or call - systemd1's - org.freedesktop.systemd1.Manager.KExec D-Bus method - directly. - - - - local-fs.target - - systemd-fstab-generator3 - automatically adds dependencies of type - Before= to all mount units that refer to - local mount points for this target unit. In addition, it - adds dependencies of type Wants= to this - target unit for those mounts listed in - /etc/fstab that have the - mount option set. - - - - machines.target - - A standard target unit for starting all the containers - and other virtual machines. See systemd-nspawn@.service - for an example. - - - - multi-user.target - - A special target unit for setting up a multi-user - system (non-graphical). This is pulled in by - graphical.target. - - Units that are needed for a multi-user system shall - add Wants= dependencies for their unit to - this unit during installation. This is best configured via - WantedBy=multi-user.target in the unit's - [Install] section. - - - - network-online.target - - Units that strictly require a configured network - connection should pull in - network-online.target (via a - Wants= type dependency) and order - themselves after it. This target unit is intended to pull in - a service that delays further execution until the network is - sufficiently set up. What precisely this requires is left to - the implementation of the network managing service. - - Note the distinction between this unit and - network.target. This unit is an active - unit (i.e. pulled in by the consumer rather than the - provider of this functionality) and pulls in a service which - possibly adds substantial delays to further execution. In - contrast, network.target is a passive - unit (i.e. pulled in by the provider of the functionality, - rather than the consumer) that usually does not delay - execution much. Usually, network.target - is part of the boot of most systems, while - network-online.target is not, except - when at least one unit requires it. Also see Running - Services After the Network is up for more - information. - - All mount units for remote network file systems - automatically pull in this unit, and order themselves after - it. Note that networking daemons that simply provide - functionality to other hosts generally do not need to pull - this in. - - systemd automatically adds dependencies of type Wants= and After= - for this target unit to all SysV init script service units with an LSB header referring to the - $network facility. - - Note that this unit is only useful during the original system start-up logic. After the system has - completed booting up, it will not track the online state of the system anymore. Due to this it cannot be used - as a network connection monitor concept, it is purely a one-time system start-up concept. + + + -.mount + + The root mount point, i.e. the mount unit for the / + path. This unit is unconditionally active, during the entire time the system is up, as + this mount point is where the basic userspace is running from. - - - paths.target - - A special target unit that sets up all path units (see - systemd.path5 - for details) that shall be active after boot. + - It is recommended that path units installed by - applications get pulled in via Wants= - dependencies from this unit. This is best configured via a - WantedBy=paths.target in the path unit's - [Install] section. - - - - poweroff.target - - A special target unit for shutting down and powering - off the system. + + basic.target + + A special target unit covering basic boot-up. - Applications wanting to power off the system should not start this unit - directly, but should instead execute systemctl poweroff - (possibly with the option) or call - systemd-logind8's - org.freedesktop.login1.Manager.PowerOff D-Bus method - directly. + systemd automatically adds dependency of the type + After= for this target unit to all + services (except for those with + DefaultDependencies=no). - runlevel0.target is an alias for - this target unit, for compatibility with SysV. - - - - reboot.target - - A special target unit for shutting down and rebooting - the system. + Usually, this should pull-in all local mount points plus + /var, /tmp and + /var/tmp, swap devices, sockets, timers, + path units and other basic initialization necessary for general + purpose daemons. The mentioned mount points are special cased + to allow them to be remote. + - Applications wanting to reboot the system should not start this unit - directly, but should instead execute systemctl reboot - (possibly with the option) or call - systemd-logind8's - org.freedesktop.login1.Manager.Reboot D-Bus method - directly. + This target usually does not pull in any non-target units + directly, but rather does so indirectly via other early boot targets. + It is instead meant as a synchronization point for late boot + services. Refer to + bootup7 + for details on the targets involved. + - runlevel6.target is an alias for - this target unit, for compatibility with SysV. - - - - remote-cryptsetup.target - - Similar to cryptsetup.target, but for encrypted - devices which are accessed over the network. It is used for - crypttab8 - entries marked with . - - - - remote-fs.target - - Similar to local-fs.target, but - for remote mount points. + + + + ctrl-alt-del.target + + systemd starts this target whenever Control+Alt+Del is + pressed on the console. Usually, this should be aliased + (symlinked) to reboot.target. + + + + cryptsetup.target + + A target that pulls in setup services for all + encrypted block devices. + + + + dbus.service + + A special unit for the D-Bus bus daemon. As soon as + this service is fully started up systemd will connect to it + and register its service. + + + + dbus.socket + + A special unit for the D-Bus system bus socket. All + units with Type=dbus automatically gain a + dependency on this unit. + + + + default.target + + The default unit systemd starts at bootup. Usually, + this should be aliased (symlinked) to + multi-user.target or + graphical.target. - systemd automatically adds dependencies of type - After= for this target unit to all SysV - init script service units with an LSB header referring to - the $remote_fs facility. - - - - rescue.target - - A special target unit that pulls in the base system (including system mounts) and spawns a rescue - shell. Isolate to this target in order to administer the system in single-user mode with all file systems - mounted but with no services running, except for the most basic. Compare with - emergency.target, which is much more reduced and does not provide the file systems or - most basic services. Compare with multi-user.target, this target could be seen as - single-user.target. + The default unit systemd starts at bootup can be + overridden with the systemd.unit= kernel + command line option. + + + + display-manager.service + + The display manager service. Usually, this should be + aliased (symlinked) to gdm.service or a + similar display manager service. + + + + emergency.target + + A special target unit that starts an emergency shell on the main console. This + target does not pull in any services or mounts. It is the most minimal version of + starting the system in order to acquire an interactive shell; the only processes running + are usually just the system manager (PID 1) and the shell process. This unit is supposed + to be used with the kernel command line option systemd.unit=; it is + also used when a file system check on a required file system fails, and boot-up cannot + continue. Compare with rescue.target, which serves a similar + purpose, but also starts the most basic services and mounts all file systems. - runlevel1.target is an alias for this target unit, for compatibility with - SysV. + Use the systemd.unit=emergency.target kernel command line + option to boot into this mode. A short alias for this kernel command line option is + emergency, for compatibility with SysV. - Use the systemd.unit=rescue.target kernel command line option to boot into this - mode. A short alias for this kernel command line option is 1, for compatibility with - SysV. - - - - runlevel2.target - runlevel3.target - runlevel4.target - runlevel5.target - - These are targets that are called whenever the SysV - compatibility code asks for runlevel 2, 3, 4, 5, - respectively. It is a good idea to make this an alias for - (i.e. symlink to) graphical.target - (for runlevel 5) or multi-user.target - (the others). - - - - shutdown.target - - A special target unit that terminates the services on - system shutdown. + In many ways booting into emergency.target is similar to the + effect of booting with init=/bin/sh on the kernel command line, + except that emergency mode provides you with the full system and service manager, and + allows starting individual units in order to continue the boot process in steps. + + + + exit.target + + A special service unit for shutting down the system or + user service manager. It is equivalent to + poweroff.target on non-container + systems, and also works in containers. - Services that shall be terminated on system shutdown - shall add Conflicts= and - Before= dependencies to this unit for - their service unit, which is implicitly done when - DefaultDependencies=yes is set (the - default). - - - - sigpwr.target - - A special target that is started when systemd receives - the SIGPWR process signal, which is normally sent by the - kernel or UPS daemons when power fails. - - - - sleep.target - - A special target unit that is pulled in by - suspend.target, - hibernate.target and - hybrid-sleep.target and may be used to - hook units into the sleep state logic. - - - - slices.target - - A special target unit that sets up all slice units (see - systemd.slice5 for - details) that shall be active after boot. By default the generic system.slice - slice unit, as well as the root slice unit -.slice, is pulled in and ordered before - this unit (see below). + systemd will start this unit when it receives the + SIGTERM or SIGINT + signal when running as user service daemon. - It's a good idea to add WantedBy=slices.target lines to the [Install] - section of all slices units that may be installed dynamically. - - - - sockets.target - - A special target unit that sets up all socket - units (see - systemd.socket5 - for details) that shall be active after boot. + Normally, this (indirectly) pulls in + shutdown.target, which in turn should be + conflicted by all units that want to be scheduled for + shutdown when the service manager starts to exit. + + + + final.target + + A special target unit that is used during the shutdown + logic and may be used to pull in late services after all + normal services are already terminated and all mounts + unmounted. + + + + + getty.target + + A special target unit that pulls in statically + configured local TTY getty instances. + + + + + graphical.target + + A special target unit for setting up a graphical login + screen. This pulls in + multi-user.target. - Services that can be socket-activated shall add - Wants= dependencies to this unit for - their socket unit during installation. This is best - configured via a WantedBy=sockets.target - in the socket unit's [Install] - section. - - - - suspend.target - - A special target unit for suspending the system. This - pulls in sleep.target. - - - - swap.target - - Similar to local-fs.target, but - for swap partitions and swap files. - - - - sysinit.target - - systemd automatically adds dependencies of the types - Requires= and After= - for this target unit to all services (except for those with - DefaultDependencies=no). + Units that are needed for graphical logins shall add + Wants= dependencies for their unit to + this unit (or multi-user.target) during + installation. This is best configured via + WantedBy=graphical.target in the unit's + [Install] section. + + + + hibernate.target + + A special target unit for hibernating the system. This + pulls in sleep.target. + + + + hybrid-sleep.target + + A special target unit for hibernating and suspending + the system at the same time. This pulls in + sleep.target. + + + + suspend-then-hibernate.target + + A special target unit for suspending the system for a period + of time, waking it and putting it into hibernate. This pulls in + sleep.target. + + - This target pulls in the services required for system - initialization. System services pulled in by this target should - declare DefaultDependencies=no and specify - all their dependencies manually, including access to anything - more than a read only root filesystem. For details on the - dependencies of this target, refer to - bootup7. - - - - - syslog.socket - - The socket unit syslog implementations should listen - on. All userspace log messages will be made available on - this socket. For more information about syslog integration, - please consult the Syslog - Interface document. - - - - system-update.target - system-update-pre.target - system-update-cleanup.service - - A special target unit that is used for offline system updates. - systemd-system-update-generator8 - will redirect the boot process to this target if /system-update - exists. For more information see - systemd.offline-updates7. - + + halt.target + + A special target unit for shutting down and halting + the system. Note that this target is distinct from + poweroff.target in that it generally + really just halts the system rather than powering it + down. - Updates should happen before the system-update.target is reached, and the services - which implement them should cause the machine to reboot. The main units executing the update should order - themselves after system-update-pre.target but not pull it in. Services which want to run - during system updates only, but before the actual system update is executed should order themselves before - this unit and pull it in. As a safety measure, if this does not happen, and - /system-update still exists after system-update.target is reached, - system-update-cleanup.service will remove this symlink and reboot the machine. - - - - timers.target - - A special target unit that sets up all timer units - (see - systemd.timer5 - for details) that shall be active after boot. + Applications wanting to halt the system should not start this unit + directly, but should instead execute systemctl halt + (possibly with the option) or call + systemd1's + org.freedesktop.systemd1.Manager.Halt D-Bus method + directly. + + + + init.scope + + This scope unit is where the system and service manager (PID 1) itself resides. It + is active as long as the system is running. + + + + initrd-fs.target + + systemd-fstab-generator3 + automatically adds dependencies of type + Before= to + sysroot-usr.mount and all mount points + found in /etc/fstab that have + and not have + mount options set. + + + + initrd-root-device.target + + A special initrd target unit that is reached when the root filesystem device is available, but before + it has been mounted. + systemd-fstab-generator3 + and + systemd-gpt-auto-generator3 + automatically setup the appropriate dependencies to make this happen. + + + + + initrd-root-fs.target + + systemd-fstab-generator3 + automatically adds dependencies of type + Before= to the + sysroot.mount unit, which is generated + from the kernel command line. + + + + + kbrequest.target + + systemd starts this target whenever Alt+ArrowUp is + pressed on the console. Note that any user with physical access + to the machine will be able to do this, without authentication, + so this should be used carefully. + + + + kexec.target + + A special target unit for shutting down and rebooting + the system via kexec. - It is recommended that timer units installed by - applications get pulled in via Wants= - dependencies from this unit. This is best configured via - WantedBy=timers.target in the timer - unit's [Install] section. - - - - umount.target - - A special target unit that unmounts all mount and - automount points on system shutdown. + Applications wanting to reboot the system should not start this unit + directly, but should instead execute systemctl kexec + (possibly with the option) or call + systemd1's + org.freedesktop.systemd1.Manager.KExec D-Bus method + directly. + + + + local-fs.target + + systemd-fstab-generator3 + automatically adds dependencies of type + Before= to all mount units that refer to + local mount points for this target unit. In addition, it + adds dependencies of type Wants= to this + target unit for those mounts listed in + /etc/fstab that have the + mount option set. + + + + machines.target + + A standard target unit for starting all the containers + and other virtual machines. See systemd-nspawn@.service + for an example. + + + + multi-user.target + + A special target unit for setting up a multi-user + system (non-graphical). This is pulled in by + graphical.target. - Mounts that shall be unmounted on system shutdown - shall add Conflicts dependencies to this unit for their - mount unit, which is implicitly done when - DefaultDependencies=yes is set (the - default). - - + Units that are needed for a multi-user system shall + add Wants= dependencies for their unit to + this unit during installation. This is best configured via + WantedBy=multi-user.target in the unit's + [Install] section. + + + + network-online.target + + Units that strictly require a configured network + connection should pull in + network-online.target (via a + Wants= type dependency) and order + themselves after it. This target unit is intended to pull in + a service that delays further execution until the network is + sufficiently set up. What precisely this requires is left to + the implementation of the network managing service. - + Note the distinction between this unit and + network.target. This unit is an active + unit (i.e. pulled in by the consumer rather than the + provider of this functionality) and pulls in a service which + possibly adds substantial delays to further execution. In + contrast, network.target is a passive + unit (i.e. pulled in by the provider of the functionality, + rather than the consumer) that usually does not delay + execution much. Usually, network.target + is part of the boot of most systems, while + network-online.target is not, except + when at least one unit requires it. Also see Running + Services After the Network is up for more + information. + + All mount units for remote network file systems + automatically pull in this unit, and order themselves after + it. Note that networking daemons that simply provide + functionality to other hosts generally do not need to pull + this in. + + systemd automatically adds dependencies of type Wants= and + After= for this target unit to all SysV init script service units + with an LSB header referring to the $network facility. + + Note that this unit is only useful during the original system start-up + logic. After the system has completed booting up, it will not track the online state of + the system anymore. Due to this it cannot be used as a network connection monitor + concept, it is purely a one-time system start-up concept. + + + + paths.target + + A special target unit that sets up all path units (see + systemd.path5 + for details) that shall be active after boot. + + It is recommended that path units installed by + applications get pulled in via Wants= + dependencies from this unit. This is best configured via a + WantedBy=paths.target in the path unit's + [Install] section. + + + + poweroff.target + + A special target unit for shutting down and powering + off the system. + + Applications wanting to power off the system should not start this unit + directly, but should instead execute systemctl poweroff + (possibly with the option) or call + systemd-logind8's + org.freedesktop.login1.Manager.PowerOff D-Bus method + directly. + + runlevel0.target is an alias for + this target unit, for compatibility with SysV. + + + + reboot.target + + A special target unit for shutting down and rebooting + the system. + + Applications wanting to reboot the system should not start this unit + directly, but should instead execute systemctl reboot + (possibly with the option) or call + systemd-logind8's + org.freedesktop.login1.Manager.Reboot D-Bus method + directly. + + runlevel6.target is an alias for + this target unit, for compatibility with SysV. + + + + remote-cryptsetup.target + + Similar to cryptsetup.target, but for encrypted + devices which are accessed over the network. It is used for + crypttab8 + entries marked with . + + + + remote-fs.target + + Similar to local-fs.target, but + for remote mount points. + + systemd automatically adds dependencies of type + After= for this target unit to all SysV + init script service units with an LSB header referring to + the $remote_fs facility. + + + + rescue.target + + A special target unit that pulls in the base system (including system mounts) and + spawns a rescue shell. Isolate to this target in order to administer the system in + single-user mode with all file systems mounted but with no services running, except for + the most basic. Compare with emergency.target, which is much more + reduced and does not provide the file systems or most basic services. Compare with + multi-user.target, this target could be seen as + single-user.target. + + runlevel1.target is an alias for this target unit, for + compatibility with SysV. + + Use the systemd.unit=rescue.target kernel command line option + to boot into this mode. A short alias for this kernel command line option is + 1, for compatibility with SysV. + + + + runlevel2.target + runlevel3.target + runlevel4.target + runlevel5.target + + These are targets that are called whenever the SysV + compatibility code asks for runlevel 2, 3, 4, 5, + respectively. It is a good idea to make this an alias for + (i.e. symlink to) graphical.target + (for runlevel 5) or multi-user.target + (the others). + + + + shutdown.target + + A special target unit that terminates the services on + system shutdown. + + Services that shall be terminated on system shutdown + shall add Conflicts= and + Before= dependencies to this unit for + their service unit, which is implicitly done when + DefaultDependencies=yes is set (the + default). + + + + sigpwr.target + + A special target that is started when systemd receives + the SIGPWR process signal, which is normally sent by the + kernel or UPS daemons when power fails. + + + + sleep.target + + A special target unit that is pulled in by + suspend.target, + hibernate.target and + hybrid-sleep.target and may be used to + hook units into the sleep state logic. + + + + slices.target + + A special target unit that sets up all slice units (see + systemd.slice5 + for details) that shall be active after boot. By default the generic + system.slice slice unit, as well as the root slice unit + -.slice, is pulled in and ordered before this unit (see + below). + + It's a good idea to add WantedBy=slices.target lines to the + [Install] section of all slices units that may be installed + dynamically. + + + + sockets.target + + A special target unit that sets up all socket + units (see + systemd.socket5 + for details) that shall be active after boot. + + Services that can be socket-activated shall add + Wants= dependencies to this unit for + their socket unit during installation. This is best + configured via a WantedBy=sockets.target + in the socket unit's [Install] + section. + + + + suspend.target + + A special target unit for suspending the system. This + pulls in sleep.target. + + + + swap.target + + Similar to local-fs.target, but + for swap partitions and swap files. + + + + sysinit.target + + systemd automatically adds dependencies of the types + Requires= and After= + for this target unit to all services (except for those with + DefaultDependencies=no). + + This target pulls in the services required for system + initialization. System services pulled in by this target should + declare DefaultDependencies=no and specify + all their dependencies manually, including access to anything + more than a read only root filesystem. For details on the + dependencies of this target, refer to + bootup7. + + + + + syslog.socket + + The socket unit syslog implementations should listen + on. All userspace log messages will be made available on + this socket. For more information about syslog integration, + please consult the Syslog + Interface document. + + + + system-update.target + system-update-pre.target + system-update-cleanup.service + + A special target unit that is used for offline system updates. + systemd-system-update-generator8 + will redirect the boot process to this target if /system-update + exists. For more information see + systemd.offline-updates7. + + + Updates should happen before the system-update.target is + reached, and the services which implement them should cause the machine to reboot. The + main units executing the update should order themselves after + system-update-pre.target but not pull it in. Services which want to + run during system updates only, but before the actual system update is executed should + order themselves before this unit and pull it in. As a safety measure, if this does not + happen, and /system-update still exists after + system-update.target is reached, + system-update-cleanup.service will remove this symlink and reboot + the machine. + + + + timers.target + + A special target unit that sets up all timer units + (see + systemd.timer5 + for details) that shall be active after boot. + + It is recommended that timer units installed by + applications get pulled in via Wants= + dependencies from this unit. This is best configured via + WantedBy=timers.target in the timer + unit's [Install] section. + + + + umount.target + + A special target unit that unmounts all mount and + automount points on system shutdown. + + Mounts that shall be unmounted on system shutdown + shall add Conflicts dependencies to this unit for their + mount unit, which is implicitly done when + DefaultDependencies=yes is set (the + default). + + + + + + + + Special System Units for Devices + + Some target units are automatically pulled in as devices of + certain kinds show up in the system. These may be used to + automatically activate various services based on the specific type + of the available hardware. + + + + bluetooth.target + + This target is started automatically as soon as a + Bluetooth controller is plugged in or becomes available at + boot. + + This may be used to pull in Bluetooth management + daemons dynamically when Bluetooth hardware is found. + + + + printer.target + + This target is started automatically as soon as a + printer is plugged in or becomes available at boot. + + This may be used to pull in printer management daemons + dynamically when printer hardware is found. + + + + smartcard.target + + This target is started automatically as soon as a + smartcard controller is plugged in or becomes available at + boot. + + This may be used to pull in smartcard management + daemons dynamically when smartcard hardware is found. + + + + sound.target + + This target is started automatically as soon as a + sound card is plugged in or becomes available at + boot. + + This may be used to pull in audio management daemons + dynamically when audio hardware is found. + + + + + + + Special Passive System Units + + A number of special system targets are defined that can be + used to properly order boot-up of optional services. These targets + are generally not part of the initial boot transaction, unless + they are explicitly pulled in by one of the implementing services. + Note specifically that these passive target + units are generally not pulled in by the consumer of a service, + but by the provider of the service. This means: a consuming + service should order itself after these targets (as appropriate), + but not pull it in. A providing service should order itself before + these targets (as appropriate) and pull it in (via a + Wants= type dependency). + + Note that these passive units cannot be started manually, + i.e. systemctl start time-sync.target will fail + with an error. They can only be pulled in by dependency. This is + enforced since they exist for ordering purposes only and thus are + not useful as only unit within a transaction. + + + + cryptsetup-pre.target + + This passive target unit may be pulled in by services + that want to run before any encrypted block device is set + up. All encrypted block devices are set up after this target + has been reached. Since the shutdown order is implicitly the + reverse start-up order between units, this target is + particularly useful to ensure that a service is shut down + only after all encrypted block devices are fully + stopped. + + + + getty-pre.target + + A special passive target unit. Users of this target + are expected to pull it in the boot transaction via + a dependency (e.g. Wants=). Order your + unit before this unit if you want to make use of the console + just before getty is started. + + + + + local-fs-pre.target + + This target unit is + automatically ordered before + all local mount points marked + with + (see above). It can be used to + execute certain units before + all local mounts. + + + + network.target + + This unit is supposed to indicate when network + functionality is available, but it is only very weakly + defined what that is supposed to mean, with one exception: + at shutdown, a unit that is ordered after + network.target will be stopped before + the network — to whatever level it might be set up then — + is shut down. It is hence useful when writing service files + that require network access on shutdown, which should order + themselves after this target, but not pull it in. Also see + Running + Services After the Network is up for more + information. Also see + network-online.target described + above. + + + + network-pre.target + + This passive target unit may be pulled in by services + that want to run before any network is set up, for example + for the purpose of setting up a firewall. All network + management software orders itself after this target, but + does not pull it in. + + + + nss-lookup.target + + A target that should be used as synchronization point for all host/network name + service lookups. Note that this is independent of UNIX user/group name lookups for which + nss-user-lookup.target should be used. All services for which the + availability of full host/network name resolution is essential should be ordered after + this target, but not pull it in. systemd automatically adds dependencies of type + After= for this target unit to all SysV init script service units + with an LSB header referring to the $named facility. + + + + nss-user-lookup.target + + A target that should be used as synchronization point for all regular UNIX + user/group name service lookups. Note that this is independent of host/network name + lookups for which nss-lookup.target should be used. All services + for which the availability of the full user/group database is essential should be + ordered after this target, but not pull it in. All services which provide parts of the + user/group database should be ordered before this target, and pull it in. Note that this + unit is only relevant for regular users and groups — system users and groups are + required to be resolvable during earliest boot already, and hence do not need any + special ordering against this target. + + + + remote-fs-pre.target + + This target unit is automatically ordered before all + mount point units (see above) and cryptsetup devices + marked with the . It can be used to run + certain units before remote encrypted devices and mounts are established. + Note that this unit is generally not part of the initial + transaction, unless the unit that wants to be ordered before + all remote mounts pulls it in via a + Wants= type dependency. If the unit wants + to be pulled in by the first remote mount showing up, it + should use network-online.target (see + above). + + + + rpcbind.target + + The portmapper/rpcbind pulls in this target and orders + itself before it, to indicate its availability. systemd + automatically adds dependencies of type + After= for this target unit to all SysV + init script service units with an LSB header referring to + the $portmap facility. + + + + time-sync.target + + Services responsible for synchronizing the system + clock from a remote source (such as NTP client + implementations) should pull in this target and order + themselves before it. All services where correct time is + essential should be ordered after this unit, but not pull it + in. systemd automatically adds dependencies of type + After= for this target unit to all SysV + init script service units with an LSB header referring to + the $time facility. + + + + + + + Special Slice Units + + There are four .slice units which form the basis of the hierarchy for + assignment of resources for services, users, and virtual machines or containers. See + systemd.slice7 + for details about slice units. + + + + -.slice + + The root slice is the root of the slice hierarchy. It usually does not contain + units directly, but may be used to set defaults for the whole tree. + + + + + system.slice + + By default, all system services started by + systemd are found in this slice. + + + + + user.slice + + By default, all user processes and services started on + behalf of the user, including the per-user systemd instance + are found in this slice. This is pulled in by + systemd-logind.service + + + + + machine.slice + + By default, all virtual machines and containers + registered with systemd-machined are + found in this slice. This is pulled in by + systemd-machined.service + + + + - Special System Units for Devices + Units managed by the user's service manager - Some target units are automatically pulled in as devices of - certain kinds show up in the system. These may be used to - automatically activate various services based on the specific type - of the available hardware. + + Special User Units - - - bluetooth.target - - This target is started automatically as soon as a - Bluetooth controller is plugged in or becomes available at - boot. + When systemd runs as a user instance, the following special + units are available, which have similar definitions as their + system counterparts: + exit.target, + default.target, + shutdown.target, + sockets.target, + timers.target, + paths.target, + bluetooth.target, + printer.target, + smartcard.target, + sound.target. + - This may be used to pull in Bluetooth management - daemons dynamically when Bluetooth hardware is found. - - - - printer.target - - This target is started automatically as soon as a - printer is plugged in or becomes available at boot. + + Special Passive User Units - This may be used to pull in printer management daemons - dynamically when printer hardware is found. - - - - smartcard.target - - This target is started automatically as soon as a - smartcard controller is plugged in or becomes available at - boot. + + + graphical-session.target + + This target is active whenever any graphical session is running. It is used to + stop user services which only apply to a graphical (X, Wayland, etc.) session when the + session is terminated. Such services should have + PartOf=graphical-session.target in their [Unit] + section. A target for a particular session (e. g. + gnome-session.target) starts and stops + graphical-session.target with + BindsTo=graphical-session.target. - This may be used to pull in smartcard management - daemons dynamically when smartcard hardware is found. - - - - sound.target - - This target is started automatically as soon as a - sound card is plugged in or becomes available at - boot. + Which services are started by a session target is determined by the + Wants= and Requires= dependencies. For services + that can be enabled independently, symlinks in .wants/ and + .requires/ should be used, see + systemd.unit5. + Those symlinks should either be shipped in packages, or should be added dynamically + after installation, for example using systemctl add-wants, see + systemctl1. + - This may be used to pull in audio management daemons - dynamically when audio hardware is found. - - - - + + Nautilus as part of a GNOME session - - Special Passive System Units + gnome-session.target pulls in Nautilus as top-level service: - A number of special system targets are defined that can be - used to properly order boot-up of optional services. These targets - are generally not part of the initial boot transaction, unless - they are explicitly pulled in by one of the implementing services. - Note specifically that these passive target - units are generally not pulled in by the consumer of a service, - but by the provider of the service. This means: a consuming - service should order itself after these targets (as appropriate), - but not pull it in. A providing service should order itself before - these targets (as appropriate) and pull it in (via a - Wants= type dependency). + [Unit] + Description=User systemd services for GNOME graphical session + Wants=nautilus.service + BindsTo=graphical-session.target - Note that these passive units cannot be started manually, - i.e. systemctl start time-sync.target will fail - with an error. They can only be pulled in by dependency. This is - enforced since they exist for ordering purposes only and thus are - not useful as only unit within a transaction. + nautilus.service gets stopped when the session stops: - - - cryptsetup-pre.target - - This passive target unit may be pulled in by services - that want to run before any encrypted block device is set - up. All encrypted block devices are set up after this target - has been reached. Since the shutdown order is implicitly the - reverse start-up order between units, this target is - particularly useful to ensure that a service is shut down - only after all encrypted block devices are fully - stopped. - - - - getty-pre.target - - A special passive target unit. Users of this target - are expected to pull it in the boot transaction via - a dependency (e.g. Wants=). Order your - unit before this unit if you want to make use of the console - just before getty is started. - - - - - local-fs-pre.target - - This target unit is - automatically ordered before - all local mount points marked - with - (see above). It can be used to - execute certain units before - all local mounts. - - - - network.target - - This unit is supposed to indicate when network - functionality is available, but it is only very weakly - defined what that is supposed to mean, with one exception: - at shutdown, a unit that is ordered after - network.target will be stopped before - the network — to whatever level it might be set up then — - is shut down. It is hence useful when writing service files - that require network access on shutdown, which should order - themselves after this target, but not pull it in. Also see - Running - Services After the Network is up for more - information. Also see - network-online.target described - above. - - - - network-pre.target - - This passive target unit may be pulled in by services - that want to run before any network is set up, for example - for the purpose of setting up a firewall. All network - management software orders itself after this target, but - does not pull it in. - - - - nss-lookup.target - - A target that should be used as synchronization point for all host/network name service lookups. Note - that this is independent of UNIX user/group name lookups for which nss-user-lookup.target - should be used. All services for which the availability of full host/network name resolution is essential - should be ordered after this target, but not pull it in. systemd automatically adds dependencies of type - After= for this target unit to all SysV init script service units with an LSB header - referring to the $named facility. - - - - nss-user-lookup.target - - A target that should be used as synchronization point for all regular UNIX user/group name service - lookups. Note that this is independent of host/network name lookups for which - nss-lookup.target should be used. All services for which the availability of the full - user/group database is essential should be ordered after this target, but not pull it in. All services which - provide parts of the user/group database should be ordered before this target, and pull it in. Note that this - unit is only relevant for regular users and groups — system users and groups are required to be resolvable - during earliest boot already, and hence do not need any special ordering against this target. - - - - remote-fs-pre.target - - This target unit is automatically ordered before all - mount point units (see above) and cryptsetup devices - marked with the . It can be used to run - certain units before remote encrypted devices and mounts are established. - Note that this unit is generally not part of the initial - transaction, unless the unit that wants to be ordered before - all remote mounts pulls it in via a - Wants= type dependency. If the unit wants - to be pulled in by the first remote mount showing up, it - should use network-online.target (see - above). - - - - rpcbind.target - - The portmapper/rpcbind pulls in this target and orders - itself before it, to indicate its availability. systemd - automatically adds dependencies of type - After= for this target unit to all SysV - init script service units with an LSB header referring to - the $portmap facility. - - - - time-sync.target - - Services responsible for synchronizing the system - clock from a remote source (such as NTP client - implementations) should pull in this target and order - themselves before it. All services where correct time is - essential should be ordered after this unit, but not pull it - in. systemd automatically adds dependencies of type - After= for this target unit to all SysV - init script service units with an LSB header referring to - the $time facility. - - - - + [Unit] + Description=Render the desktop icons with Nautilus + PartOf=graphical-session.target - - Special User Units + [Service] + … + + + - When systemd runs as a user instance, the following special - units are available, which have similar definitions as their - system counterparts: - exit.target, - default.target, - shutdown.target, - sockets.target, - timers.target, - paths.target, - bluetooth.target, - printer.target, - smartcard.target, - sound.target. - - - - Special Passive User Units - - - - graphical-session.target - - This target is active whenever any graphical session is running. It is used to stop user services which - only apply to a graphical (X, Wayland, etc.) session when the session is terminated. Such services should - have PartOf=graphical-session.target in their [Unit] section. A target - for a particular session (e. g. gnome-session.target) starts and stops - graphical-session.target with BindsTo=graphical-session.target. - - Which services are started by a session target is determined by the Wants= and - Requires= dependencies. For services that can be enabled independently, symlinks in - .wants/ and .requires/ should be used, see - systemd.unit5. Those - symlinks should either be shipped in packages, or should be added dynamically after installation, for example - using systemctl add-wants, see - systemctl1. - - - - Nautilus as part of a GNOME session - - gnome-session.target pulls in Nautilus as top-level service: - - [Unit] -Description=User systemd services for GNOME graphical session -Wants=nautilus.service -BindsTo=graphical-session.target - - nautilus.service gets stopped when the session stops: - - [Unit] -Description=Render the desktop icons with Nautilus -PartOf=graphical-session.target - -[Service] -… - - - - - - graphical-session-pre.target - - This target contains services which set up the environment or global configuration of a graphical - session, such as SSH/GPG agents (which need to export an environment variable into all desktop processes) or - migration of obsolete d-conf keys after an OS upgrade (which needs to happen before starting any process that - might use them). This target must be started before starting a graphical session like - gnome-session.target. - - - - - - - - Special Slice Units - - There are four .slice units which form the basis of the hierarchy for assignment of - resources for services, users, and virtual machines or containers. See - systemd.slice7 for details about slice - units. - - - - -.slice - - The root slice is the root of the slice hierarchy. It usually does not contain units directly, but may - be used to set defaults for the whole tree. - - - - - system.slice - - By default, all system services started by - systemd are found in this slice. - - - - - user.slice - - By default, all user processes and services started on - behalf of the user, including the per-user systemd instance - are found in this slice. This is pulled in by - systemd-logind.service - - - - - machine.slice - - By default, all virtual machines and containers - registered with systemd-machined are - found in this slice. This is pulled in by - systemd-machined.service - - - + + graphical-session-pre.target + + This target contains services which set up the environment or global configuration + of a graphical session, such as SSH/GPG agents (which need to export an environment + variable into all desktop processes) or migration of obsolete d-conf keys after an OS + upgrade (which needs to happen before starting any process that might use them). This + target must be started before starting a graphical session like + gnome-session.target. + + + + @@ -1052,7 +1075,8 @@ PartOf=graphical-session.target systemd.target5, systemd.slice5, bootup7, - systemd-fstab-generator8 + systemd-fstab-generator8, + user@.service5 diff --git a/man/user@.service.xml b/man/user@.service.xml new file mode 100644 index 00000000000..fc9c3e786c1 --- /dev/null +++ b/man/user@.service.xml @@ -0,0 +1,190 @@ + + + + + + + user@.service + systemd + + + + user@.service + 5 + + + + user@.service + user-runtime-dir@.service + System units to manager user processes + + + + user@UID.service + user-runtime-dir@UID.service + user-UID.slice + + + + Description + + The + systemd1 + system manager (PID 1) starts user manager instances as + user@UID.service, where the user's numerical UID + is used as the instance identifier. Each systemd --user instance manages a + hierarchy of its own units. See + systemd1 for + a discussion of systemd units and + systemd.special1 + for a list of units that form the basis of the unit hierarchies of system and user units. + + user@UID.service is accompanied by the + system unit user-runtime-dir@UID.service, which + creates the user's runtime directory + /run/user/UID, and then removes it when this + unit is stopped. + + User processes may be started by the user@.service instance, in which + case they will be part of that unit in the system hierarchy. They may also be started elsewhere, + for example by + sshd8 or a + display manager like gdm, in which case they form a .scope unit (see + systemd.scope5). + Both user@UID.service and the scope units are + collected under a user-UID.slice. + + Individual user-UID.slice slices are + collected under user.slice, see + systemd.special8. + + + + + Controlling resources for logged-in users + + Options that control resources available to logged-in users can be configured at a few + different levels. As described in the previous section, user.slice contains + processes of all users, so any resource limits on that slice apply to all users together. The + usual way to configure them would be through drop-ins, e.g. /etc/systemd/system/user.slice.d/resources.conf. + + + The processes of a single user are collected under + user-UID.slice. Resource limits for that user + can be configured through drop-ins for that unit, e.g. /etc/systemd/system/user-1000.slice.d/resources.conf. If the limits + should apply to all users instead, they may be configured through drop-ins for the truncated + unit name, user-.slice. For example, configuration in /etc/systemd/system/user-.slice.d/resources.conf is included in all + user-UID.slice units, see + systemd.unit5 + for a discussion of the drop-in mechanism. + + When a user logs in and a .scope unit is created for the session (see previous section), + the creation of the scope may be managed through + pam_systemd8. + This PAM module communicates with + systemd-logind8 + to create the session scope and provide access to hardware resources. Resource limits for the + scope may be configured through the PAM module configuration, see + pam_systemd8. + Configuring them through the normal unit configuration is also possible, but since + the name of the slice unit is generally unpredictable, this is less useful. + + In general any resources that apply to units may be set for + user@UID.service and the slice + units discussed above, see + systemd.resource-control5 + for an overview. + + + + Examples + + Hierarchy of control groups with two logged in users + + $ systemd-cgls +Control group /: +-.slice +├─user.slice +│ ├─user-1000.slice +│ │ ├─user@1000.service +│ │ │ ├─pulseaudio.service +│ │ │ │ └─2386 /usr/bin/pulseaudio --daemonize=no +│ │ │ └─gnome-terminal-server.service +│ │ │ └─init.scope +│ │ │ ├─ 4127 /usr/libexec/gnome-terminal-server +│ │ │ └─ 4198 zsh +│ │ … +│ │ └─session-4.scope +│ │ ├─ 1264 gdm-session-worker [pam/gdm-password] +│ │ ├─ 2339 /usr/bin/gnome-shell +│ │ … +│ │ ├─session-19.scope +│ │ ├─6497 sshd: zbyszek [priv] +│ │ ├─6502 sshd: zbyszek@pts/6 +│ │ ├─6509 -zsh +│ │ └─6602 systemd-cgls --no-pager +│ … +│ └─user-1001.slice +│ ├─session-20.scope +│ │ ├─6675 sshd: guest [priv] +│ │ ├─6708 sshd: guest@pts/6 +│ │ └─6717 -bash +│ └─user@1001.service +│ ├─init.scope +│ │ ├─6680 /usr/lib/systemd/systemd --user +│ │ └─6688 (sd-pam) +│ └─sleep.service +│ └─6706 /usr/bin/sleep 30 +… + User with UID 1000 is logged in using gdm (session-4.scope) and + ssh1 + (session-19.scope), and also has a user manager instance + running (user@1000.service). User with UID 1001 is logged + in using ssh (session-20.scope) and + also has a user manager instance running (user@1001.service). Those are all (leaf) system units, and form + part of the slice hierarchy, with user-1000.slice and + user-1001.slice below user.slice. User units are visible below the + user@.service instances (pulseaudio.service, gnome-terminal-server.service, init.scope, sleep.service). + + + + + Default user resource limits + + $ systemctl cat user-1000.slice +# /usr/lib/systemd/system/user-.slice.d/10-defaults.conf +# … +[Unit] +Description=User Slice of UID %j +After=systemd-user-sessions.service + +[Slice] +TasksMax=33% + The user-UID.slice units by default don't + have a unit file. The resource limits are set through a drop-in, which can be easily replaced + or extended following standard drop-in mechanisms discussed in the first section. + + + + + See Also + + systemd1, + systemd.service5, + systemd.slice5, + systemd.resource-control5, + systemd.exec5, + systemd.special7, + pam8 + + + diff --git a/units/user-.slice.d/10-defaults.conf b/units/user-.slice.d/10-defaults.conf index 95ab11b30be..f1d118562c7 100644 --- a/units/user-.slice.d/10-defaults.conf +++ b/units/user-.slice.d/10-defaults.conf @@ -9,6 +9,7 @@ [Unit] Description=User Slice of UID %j +Documentation=man:user@.service(5) After=systemd-user-sessions.service [Slice] diff --git a/units/user-runtime-dir@.service.in b/units/user-runtime-dir@.service.in index 8c02beda3bd..3a852b68a67 100644 --- a/units/user-runtime-dir@.service.in +++ b/units/user-runtime-dir@.service.in @@ -9,6 +9,7 @@ [Unit] Description=/run/user/%i mount wrapper +Documentation=man:user@.service(5) StopWhenUnneeded=yes [Service] diff --git a/units/user@.service.in b/units/user@.service.in index b88108e1b75..07107a66ee2 100644 --- a/units/user@.service.in +++ b/units/user@.service.in @@ -9,6 +9,7 @@ [Unit] Description=User Manager for UID %i +Documentation=man:user@.service(5) After=systemd-user-sessions.service After=user-runtime-dir@%i.service Requires=user-runtime-dir@%i.service