<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 4:35 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-15 02:39:52]:<br>
<br>
> What's wrong with monit is that it's documentation is gigantic<br>
<br>
Good documentation with a lot of examples is hardly a problem, its a bonus<br>
point for me.<br>
<br></blockquote><div><br></div><div>I think you misunderstood.</div><div><br></div><div>Monit has a massive feature surface. I'm not even going to consider it, it goes far far beyond the level of capability that's appropriate for my use case.<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">
> for a relatively trivial need.<br>
<br>
Your need, your current trivial use case. Overall project<br>
goals/design/universe should be taken into account.<br></blockquote><div><br></div><div>Sure, accept the patch or don't. I'm happy to take guidance from the OpenWRT community, but ultimately will implement the things I need the way I need them. Designing patches so that they are palatable to OpenWRT is a secondary concern. Once I have it working to the level that I'm happy with, the patch will be provided under the appropriate license, and then it's not my problem beyond helping serious efforts at integrating it.<br></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">
> If ubus is failing, there's a much larger problem than my service failing.<br>
<br>
And you don't want to recover from this even more critical situation?<br></blockquote><div><br></div><div>If UBus fails, there's not a realistic recovery option beyond restarting the system, I'd rather that be PID 1's responsibility as well.</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">
> This requires that my program be able to communicate with ubus natively and<br>
> offer a ubus endpoint that can be queried.<br>
<br>
Then use file, socket or whatever suits your use case.<br></blockquote><div><br></div><div>Of course, I will do what suits my use case. In this situation, the use case is that I want service monitoring built into the daemon that manages services.</div><div><br></div><div>I was responding to your suggestion of advertising a status string on ubus, and explaining why that's not viable.</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">
> More complicated than a simple timer in procd.<br>
<br>
Which is not flexible enough, tailored exactly to your very simple use case.<br></blockquote><div><br></div><div>Perfect is the enemy of the good. My proposal is very simple, and very flexible. It's not literally as flexible as it possibly can be while simultaneously having no negatives, but no solution is.</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">
> It's hardly bloat.<br>
<br>
Just take a look one step further.  Once OpenWrt accepts this feature its<br>
official.  What is going to happen afterwards in the OpenWrt universe? <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Folks will of course start using this feature, adding support for this feature<br>
into their critical services (take your answer to ISC dhcp support as<br>
example), which would in most cases mean local patch(es) as this feature could<br>
be hardly upstreamed.<br></blockquote><div><br></div><div>Lots of projects accept patches for specific init system features. If systemd specific patches can be upstreamed, so can procd patches.</div><div><br></div><div>Also consider that OpenWRT already has patches for lots of programs to communicate over ubus. Are you insinuating that those patches are undesirable?</div><div><br></div><div>This is the cost that comes with maintaining your own set of system services that no other project family uses. You don't see procd used in desktop distributions, or cellphones, or "infotainment" systems in cars, etc. (That I'm aware of, I'm happy to be corrected). Custom tools require customization to things.</div><div><br></div><div>Procd does not have the feature set that I require for my purposes. I am happy with other parts of the OpenWRT ecosystem, so instead of switching to a different distribution, I'm open to making contributions so everyone can benefit.<br></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">
So in the end, we're going to have not so trivial amount of local patches for<br>
ubus service watchdog support, which would break DRY principle,</blockquote><div><br></div><div>Hardly. Each package is different, so the decision making logic to communicate with a service watchdog will be different. At worst, you have 10-20 lines of code duplicated per package, and that'll be whatever quantity of boilerplate communicating with UBus requires.<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">and probably result in additional maintenance/QA work with every package version bump.<br></blockquote><div><br></div><div>Trade off between additional reliability and code complexity. It's a tale as old as software. <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">
In order to avoid this bloat, unnecessary patch hell, one would perhaps need<br>
to implement kind of monit/cron solution in procd/umonitd, so it would be<br>
possible to have custom/generic service liveliness checks defined in the<br>
service init scripts or UCI configuration.<br>
<br>
Maybe all is needed is some kind of monitrc generator from UCI configs/init<br>
scripts?<br></blockquote><div><br></div><div></div><div>Your counter proposal to a (estimated) 200-300 lines of code patch in procd, which could even be a compile-time-option, is to have services depend on a package that has more features than I know what to do with?</div><div><br></div><div>How is monit going to work with procd's jails? The whole point of the jails is to isolate services into their own mini-container type thing. So now we have to poke a hole in the jail to allow monit to monitor the service?</div><div><br></div><div>And monit isn't some magical drop-in solution. Imagine a service that doesn't already have a strong indicator of "liveness". Now that program needs to be patched for compatibility with monit, just like it would be for compatibility with procd's potential service watchdog.</div><div><br></div></div></div>