<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020 at 1:53 PM Eric Romano <<a href="mailto:gelstudios@gmail.com">gelstudios@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It does seem like process supervision would be a nice capability to<br>
have within procd.<br>
<br>
Previously I've done this by a combination of:<br>
1. trying to crash / exit the process when an inconsistent state is hit.<br>
2. monitoring for delayed writes to a timestamp pidfile in temp.<br>
<br>
procd's respawn directive can handle the first case (i forget but<br>
something like "respawn 10 5 0" did fine), but the second one...<br>
depended on a clumsy nanny process to reap / kill any that failed to<br>
update their timestamp.<br>
<br>
Feature wise, it would be nice to have more than one way to perform<br>
the process health check.<br>
<br>
Some options that come to mind are:<br>
- a ping / pong -like method via ubus<br>
- expecting the process to "touch" a specified file, which procd could<br>
read stat times for<br>
- either of the above, with the ability to trigger a refresh via<br>
signal like SIGUSR1 or SIGUSR2, etc.<br>
<br>
Would be good to hear what other methods have been tried by others,<br>
and what a generic interface to this could look like in procd's<br>
config.<br>
<br><br></blockquote><div><br></div><div>The way I'm currently doing it is to use abstract unix domain sockets. The wrapper program opens the abstract domain socket for read, and the subordinate program open for write. </div><div><br></div><div>If the wrapper program does not get at least one byte to read from whatever is writing to the socket, every $timeout then it kills the child.</div><div><br></div><div>The idea that I had in mind originally was for the service in question to need to send a message to some endpoint in ubus. This allows:</div><div>1) External programs can do the watchdog poking for the service in question. E.g. your program need not understand ubus, it only needs to know how to launch the ubus CLI program to send the message.</div><div>2) This allows for the watchdog behavior to grow additional features over time</div><div>3) This allows for the watchdog management to be seperate from procd, conceptually.</div><div><br></div><div>But I'd be happy to see other approaches as well.</div></div></div>