Hi all,
Based on [0] and in particular:
"Despite it being against the "spirit" of systemd, this is perhaps the
cleanest and most reliable: have systemd poll whatever service the
daemon is supposed to provide. For example, if the service is starting
sshd on port 22, systemd could repeatedly try connecting to port 22,
with exponential backoff, until it succeeds. This approach requires no
modification to existing daemons, and if implemented correctly, would
have minimal cost (only at daemon start time) in cpu load and startup latency."
I added a fifo listener mode for respawn. It will sit there waiting for
the specified fifo to become readable and it will restart the given program.
It discards all input on the fifo.
The monitoring tool does not exist yet but it can be written separately
and then simply do a dummy write to the respawn fifo.
Rate-limiting might have to happen somewhere but I'd like to keep respawn
dumb.
The number of writes do not correspond 1-1 with the number of invocations.
If the monitoring program writes too fast, the writes will most
probably be coalesced as far as the respawn tool is concerned. So it is
likely for N writes very close together that it will trigger only 1
invocation of the program.
What do you think?
Cheers,
sin
[0]
http://ewontfix.com/15/
Received on Mon Apr 21 2014 - 13:10:20 CEST