morgan/systemd
1
0
Fork 0
mirror of https://github.com/morgan9e/systemd synced 2026-04-14 00:14:32 +09:00
Code Issues Packages Projects Releases Wiki Activity

man: improve BindsTo= documentation

Browse Source 
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>
This commit is contained in:
Christoph Anton Mitterer
2025-10-18 05:30:12 +02:00
committed by Zbigniew Jędrzejewski-Szmek
parent 3605b3ba87
commit b3d99e2308
1 changed files with 4 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
man/systemd.unit.xml
View File

@@ -721,9 +721,10 @@
<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>