sending a RELOADING=1 notification in service A nicely changes the state of service A into "reloading (reload)", but does not trigger a reload in a service B that propagate its reload from service A. What is the purpose of notifying RELOADING=1 if it does not propagate?
I saw RELOADING=1 as a notice to systemd not start new services that depend on it until its back to READY=1. This is just my assumption. A little more detail in http://www.freedesktop.org/software/systemd/man/sd_notify.html may be needed. I don't think propagating a RELOAD to further services is needed and shouldn't be automatic. If a depending service fails I assume it will be restarted by systemd but otherwise its up the the depending service to handle transient failures of its dependencies. I was planning on using this RELOADING=1 in a database that's not accepting any changes/connections because its getting a cluster peer up to date. To me reloading doesn't imply the IPC between this an dependent services is going away or any stateful TCP connections will need to be remade. Happy to consider alternate points of view or even implementation, however as long as its documented I can deal with it.
Created attachment 111760 [details] [review] suggested fix I agree that RELOADING=1 is just a message conveying state information to systemd. However, the message has a meaning and to me a service that has ReloadPropagatedFrom= indicates that it wants to be informed of precisely this meaning.
can you provide an example when this would be used?
I was thinking on writing a daemon that listens for certain kernel events. If an event occurs, it updates the status string of its governing service and signals RELOADING=1. If other services are supposed to act on such events they can register for reload propagation and retrieve the status string. Stopping the listener service disables signaling the registered service without stopping it entirely. More specifically I was thinking of writing such a daemon to listen for a carrier and soft/hard blocks (rfkill) for a network interface.
This should work now, given that https://github.com/systemd/systemd/pull/6428 has been merged. Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.