From e52f929574773af23151efd1078879e4fe78c386 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Tue, 30 May 2023 13:35:18 +0200 Subject: [PATCH] man: extend description of .target a bit The man page is reference documentation, so we shouldn't write too much duplicate things here, but we can make the text a bit more approachable. This rewords and extends the documentation as requested and suggested in #24231 and adds some hints for the user. Closes #24231. --- man/systemd.target.xml | 67 +++++++++++++++++++++++------------------- 1 file changed, 37 insertions(+), 30 deletions(-) diff --git a/man/systemd.target.xml b/man/systemd.target.xml index 604b14e4383..f6508256e3b 100644 --- a/man/systemd.target.xml +++ b/man/systemd.target.xml @@ -26,30 +26,33 @@ Description - A unit configuration file whose name ends in - .target encodes information about a target unit - of systemd, which is used for grouping units and as well-known - synchronization points during start-up. + A unit configuration file whose name ends in .target encodes information about a + target unit of systemd. Target units are used to group units and to set synchronization points for + ordering dependencies with other unit files. This unit type has no specific options. See - systemd.unit5 - for the common options of all unit configuration files. The common - configuration items are configured in the generic [Unit] and - [Install] sections. A separate [Target] section does not exist, - since no target-specific options may be configured. - - Target units do not offer any additional functionality on - top of the generic functionality provided by units. They exist - merely to group units via dependencies (useful as boot targets), - and to establish standardized names for synchronization points - used in dependencies between units. Among other things, target - units are a more flexible replacement for SysV runlevels in the - classic SysV init system. (And for compatibility reasons special - target units such as runlevel3.target exist - which are used by the SysV runlevel compatibility code in systemd. - See - systemd.special7 - for details). + systemd.unit5 for the + common options of all unit configuration files. The common configuration items are configured in the + generic [Unit] and [Install] sections. A separate [Target] section does not exist, since no + target-specific options may be configured. + + Target units do not offer any additional functionality on top of the generic functionality provided + by units. They merely group units, allowing a single target name to be used in Wants= + and Requires= settings to establish a dependency on a set of units defined by the + target, and in Before= and After= settings to establish ordering. + Targets establish standardized names for synchronization points during boot and shutdown. Importantly, + see systemd.special7 + for examples and descriptions of standard systemd targets. + + Target units provide a more flexible replacement for SysV runlevels in the classic SysV init + system. For compatibility reasons special target units such as runlevel3.target + exist which are used by the SysV runlevel compatibility code in systemd, see + systemd.special7 for + details. + + Note that a target unit file must not be empty, lest it be considered a masked unit. It is + recommended to provide a [Unit] section which includes informative Description= and + Documentation= options. @@ -68,14 +71,18 @@ DefaultDependencies=no is set: - Target units will automatically complement all - configured dependencies of type Wants= or - Requires= with dependencies of type - After= unless DefaultDependencies=no - is set in the specified units. Note that Wants= or - Requires= must be defined in the target unit itself — if - you for example define Wants=some.target in - some.service, the automatic ordering will not be added. + Target units will automatically complement all configured dependencies of type + Wants= or Requires= with dependencies of type + After= unless DefaultDependencies=no is set in the specified + units. + + Note that the reverse is not true. For example, defining in + some.service will not automatically add the + ordering dependency for some.service. + Instead, some.service should use the primary synchronization function of target + type units, by setting a specific or + ordering dependency in its .service unit file. + Target units automatically gain Conflicts= and Before= dependencies against -- 2.47.3