[OpenWrt-Devel] Ubus based service watchdog?

[Michael Jones]

On Fri, May 15, 2020 at 4:35 AM Petr Štetiar <ynezz at true.cz> wrote:

> Michael Jones <mike at meshplusplus.com> [2020-05-15 02:39:52]:
>
> > What's wrong with monit is that it's documentation is gigantic
>
> Good documentation with a lot of examples is hardly a problem, its a bonus
> point for me.
>
>
I think you misunderstood.

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.


> > for a relatively trivial need.
>
> Your need, your current trivial use case. Overall project
> goals/design/universe should be taken into account.
>

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.

> If ubus is failing, there's a much larger problem than my service failing.
>
> And you don't want to recover from this even more critical situation?
>

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.

> This requires that my program be able to communicate with ubus natively
> and
> > offer a ubus endpoint that can be queried.
>
> Then use file, socket or whatever suits your use case.
>

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.

I was responding to your suggestion of advertising a status string on ubus,
and explaining why that's not viable.

> More complicated than a simple timer in procd.
>
> Which is not flexible enough, tailored exactly to your very simple use
> case.
>

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.

> It's hardly bloat.
>
> Just take a look one step further.  Once OpenWrt accepts this feature its
> official.  What is going to happen afterwards in the OpenWrt universe?
>

> Folks will of course start using this feature, adding support for this
> feature
> into their critical services (take your answer to ISC dhcp support as
> example), which would in most cases mean local patch(es) as this feature
> could
> be hardly upstreamed.
>

Lots of projects accept patches for specific init system features. If
systemd specific patches can be upstreamed, so can procd patches.

Also consider that OpenWRT already has patches for lots of programs to
communicate over ubus. Are you insinuating that those patches are
undesirable?

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.

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.

So in the end, we're going to have not so trivial amount of local patches
> for
> ubus service watchdog support, which would break DRY principle,


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.


> and probably result in additional maintenance/QA work with every package
> version bump.
>

Trade off between additional reliability and code complexity. It's a tale
as old as software.


> In order to avoid this bloat, unnecessary patch hell, one would perhaps
> need
> to implement kind of monit/cron solution in procd/umonitd, so it would be
> possible to have custom/generic service liveliness checks defined in the
> service init scripts or UCI configuration.
>
> Maybe all is needed is some kind of monitrc generator from UCI configs/init
> scripts?
>

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?

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200515/b9e47777/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel