<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 15, 2020 at 1:58 AM Petr Štetiar <<a href="mailto:ynezz@true.cz">ynezz@true.cz</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">Michael Jones <<a href="mailto:mike@meshplusplus.com" target="_blank">mike@meshplusplus.com</a>> [2020-05-13 12:48:49]:<br>
<br>
Hi,<br>
<br>
> I have a critical service on my OpenWRT system that needs monitoring and<br>
> re-starting if it's failed.<br>
<br>
whats wrong with monit[1]? It was designed exactly for this purpose and is<br>
much more flexible.<br>
<br></blockquote><div><br></div><div>What's wrong with monit is that it's documentation is gigantic for a relatively trivial need. This disqualifies it as being designed exactly for the purpose.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I've been looking for a mechanism in procd that would allow me to request<br>
> that my service be terminated if it did not periodically notify some<br>
> watchdog endpoint via ubus.<br>
<br>
So instead of proper error handling and crashing your service ASAP, you're now<br>
going to add another ubus layer which might possibly fail as well.</blockquote><div><br></div><div>If ubus is failing, there's a much larger problem than my service failing. <br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> You know, your service could happily ping the watchdog endpoint, yet still fail in other<br>
parts. You want something more robust.<br></blockquote><div><br></div><div>Ubus would only be pinged when the service does the thing it's designed to do. In this case, there'll be some communication with the internet that involves bi-directional communication. No risk of false positives.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I would simply add ubus status method to that critical service,</blockquote><div><br></div><div>This requires that my program be able to communicate with ubus natively and offer a ubus endpoint that can be queried.</div><div><br></div><div>UBus is fundamentally incompatible with programs that have their own event loop. Or was, last I investigated. I have not had time to dig into ubox to make the necessary improvements to allow external loop drivers.</div><div><br></div><div>Having the program being managed call "ubus call service.$servicename.watchdog ...." in whatever way it wants to is more flexible. All programs can launch sub processes, even if they have to resort to fork+exec.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> then check the<br>
output in the cron shell/Lua script and kill the service if the output of the<br>
ubus status method wouldnt match liveliness for that service.<br></blockquote><div><br></div><div>More complicated than a simple timer in procd.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In other words I think, that one can solve this use case with current<br>
solutions, no need to bloat procd.<br>
<br></blockquote><div><br></div><div>It's hardly bloat. It's a very simple feature that serves a core need in service management as a generic concern. <br></div></div></div>