When a service is reloaded (SIGHUP or reload:script), allow it to declare
that its dependents should also be reloaded/restarted. This is the
provider-side complement to the consumer-side ~ condition modifier
added in #416.
Use case
A target or service that acts as a group manager for several downstream
services. Rather than requiring every dependent to opt in with ~, the
provider declares once that its reload propagates:
service propagate:reload name:netd ...
All services with <pid/netd> or <!pid/netd> conditions would then be
reloaded/restarted when netd reloads, without needing the ~ modifier.
Relationship to other issues
Both mechanisms can coexist. ~ gives fine-grained control on the
dependent side, propagate:reload gives a simple blanket declaration
on the provider side.
Reference
systemd has PropagatesReloadTo= and ReloadPropagatedFrom= for
this purpose. See also systemd/systemd#16443 for discussion around
propagation from target units.
When a service is reloaded (SIGHUP or reload:script), allow it to declare
that its dependents should also be reloaded/restarted. This is the
provider-side complement to the consumer-side
~condition modifieradded in #416.
Use case
A target or service that acts as a group manager for several downstream
services. Rather than requiring every dependent to opt in with
~, theprovider declares once that its reload propagates:
All services with
<pid/netd>or<!pid/netd>conditions would then bereloaded/restarted when netd reloads, without needing the
~modifier.Relationship to other issues
~modifier (per-dependent opt-in)propagate:reload(blanket propagation)Both mechanisms can coexist.
~gives fine-grained control on thedependent side,
propagate:reloadgives a simple blanket declarationon the provider side.
Reference
systemd has
PropagatesReloadTo=andReloadPropagatedFrom=forthis purpose. See also systemd/systemd#16443 for discussion around
propagation from target units.