When a service crashes or is killed (e.g., SIGKILL), it transitions directly from RUNNING to HALTED, bypassing the STOPPING state where cond_clear() is normally called. This means the service's pid/ condition is never invalidated, and dependent services are never notified that the condition went away.
The pidfile plugin cannot help here either — it only watches for IN_CLOSE_WRITE events, so the IN_DELETE from pidfile removal in service_cleanup() is never delivered.
In a chain like:
A ← B <pid/A> ← C <pid/B>
Killing B with kill -9 causes B to be collected and respawned, but pid/B is never cleared. C never sees the condition go OFF and is never restarted, even though B got a new PID.
When a service crashes or is killed (e.g., SIGKILL), it transitions directly from RUNNING to HALTED, bypassing the STOPPING state where
cond_clear()is normally called. This means the service'spid/condition is never invalidated, and dependent services are never notified that the condition went away.The pidfile plugin cannot help here either — it only watches for
IN_CLOSE_WRITEevents, so theIN_DELETEfrom pidfile removal inservice_cleanup()is never delivered.In a chain like:
Killing B with
kill -9causes B to be collected and respawned, butpid/Bis never cleared. C never sees the condition go OFF and is never restarted, even though B got a new PID.