From: Zbigniew Jędrzejewski-Szmek Date: Tue, 30 May 2023 11:35:18 +0000 (+0200) Subject: man: extend description of .target a bit X-Git-Tag: v254-rc1~333^2 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=refs%2Fpull%2F27848%2Fhead;p=thirdparty%2Fsystemd.git 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. --- 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