Michael Jones <m...@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. > for a relatively trivial need. Your need, your current trivial use case. Overall project goals/design/universe should be taken into account. > 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? > 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. > More complicated than a simple timer in procd. Which is not flexible enough, tailored exactly to your very simple use case. > 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. 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, and probably result in additional maintenance/QA work with every package version bump. 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? -- ynezz _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
