[OpenWrt-Devel] Ubus based service watchdog?

[Michael Jones]

On Wed, May 13, 2020 at 1:53 PM Eric Romano <gelstudios at gmail.com> wrote:

> It does seem like process supervision would be a nice capability to
> have within procd.
>
> Previously I've done this by a combination of:
> 1. trying to crash / exit the process when an inconsistent state is hit.
> 2. monitoring for delayed writes to a timestamp pidfile in temp.
>
> procd's respawn directive can handle the first case (i forget but
> something like "respawn 10 5 0" did fine), but the second one...
> depended on a clumsy nanny process to reap / kill any that failed to
> update their timestamp.
>
> Feature wise, it would be nice to have more than one way to perform
> the process health check.
>
> Some options that come to mind are:
> - a ping / pong -like method via ubus
> - expecting the process to "touch" a specified file, which procd could
> read stat times for
> - either of the above, with the ability to trigger a refresh via
> signal like SIGUSR1 or SIGUSR2, etc.
>
> Would be good to hear what other methods have been tried by others,
> and what a generic interface to this could look like in procd's
> config.
>
>
>
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.

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.

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:
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.
2) This allows for the watchdog behavior to grow additional features over
time
3) This allows for the watchdog management to be seperate from procd,
conceptually.

But I'd be happy to see other approaches as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200513/be240920/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel