ffec78c05b
This takes inspiration from PropagatesReloadTo=, but propagates stop jobs instead of restart jobs. This is defined based on exactly two atoms: UNIT_ATOM_PROPAGATE_STOP + UNIT_ATOM_RETROACTIVE_STOP_ON_STOP. The former ensures that when the unit the dependency is originating from is stopped based on user request, we'll propagate the stop job to the target unit, too. In addition, when the originating unit suddenly stops from external causes the stopping is propagated too. Note that this does *not* include the UNIT_ATOM_CANNOT_BE_ACTIVE_WITHOUT atom (which is used by BoundBy=), i.e. this dependency is purely about propagating "edges" and not "levels", i.e. it's about propagating specific events, instead of continious states. This is supposed to be useful for dependencies between .mount units and their backing .device units. So far we either placed a BindsTo= or Requires= dependency between them. The former gave a very clear binding of the to units together, however was problematic if users establish mounnts manually with different block device sources than our configuration defines, as we there might come to the conclusion that the backing device was absent and thus we need to umount again what the user mounted. By combining Requires= with the new StopPropagatedFrom= (i.e. the inverse PropagateStopTo=) we can get behaviour that matches BindsTo= in every single atom but one: UNIT_ATOM_CANNOT_BE_ACTIVE_WITHOUT is absent, and hence the level-triggered logic doesn't apply. Replaces: #11340
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.