]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
man: improve BindsTo= documentation
authorChristoph Anton Mitterer <mail@christoph.anton.mitterer.name>
Sat, 18 Oct 2025 03:30:12 +0000 (05:30 +0200)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Thu, 20 Nov 2025 08:51:08 +0000 (09:51 +0100)
Make “effect” plural to indicate that BindsTo= also includes the other effects
of Requires= (like starting the listed units).

The documentation of Requires= already describes that the configuring unit is
stopped/restarted if any of the list units is explicitly stopped/restarted.
This made the previous wording “in addition to the effect of Requires, it
declares that if the unit bound to is stopped, this unit will be stopped too.”
ambiguous – this is no in addition, Requires= already does that, at least for
some (namely the explicit) cases.
Resolve this by making it clear what the actual difference to Requires= is and
further mention that this also includes failed units.

Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
man/systemd.unit.xml

index 3d4707cb2ce642c03098f3a6b89b445dd91ec53c..a2969739e8895384087d916736a37e153011d841 100644 (file)
         <term><varname>BindsTo=</varname></term>
 
         <listitem><para>Configures requirement dependencies, very similar in style to
-        <varname>Requires=</varname>. However, this dependency type is stronger: in addition to the effect of
-        <varname>Requires=</varname> it declares that if the unit bound to is stopped, this unit will be stopped
-        too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too.
+        <varname>Requires=</varname>. However, this dependency type is stronger: in addition to the effects of
+        <varname>Requires=</varname>, which already stops (or restarts) the configuring unit when a listed unit is
+        explicitly stopped (or restared), it also does so when a listed unit stops unexpectedly (which includes when it
+        fails).
         Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit
         might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of
         a mount unit might be unmounted without involvement of the system and service manager.</para>