On 28/12/2016 01:16, Martin Tippmann wrote: > On Tue, Dec 27, 2016 at 9:43 AM, John Crispin <j...@phrozen.org> wrote: >> Hi, >> >> currently procd service restart/reload can be triggered by config >> changes and network interface changes. from what i understand you are >> missing the following features >> >> * an option to simply run a script to check if the service should be >> started/stopped at a given interval. > > yes, something that runs a script periodically and if that check > script fails (exit != 0) the service is restarted. this would be > pretty cool! But I'm not sure if our specific usecase warrants > inclusion in procd - would be nice to have!
lookign at your previous argument it would be valid to replace procd and/or add more services, so i guess this would be the lesser evil > >> * allow hotplug events to trigger service restart/reload > > At the moment shellscripts in /etc/hotplug.d are okay for this. I'm > not too familiar with what is possible with netifd and procd already.. > something I'd thought about is: > > wan goes up (someone plugs in a cable), vpn is started due to hotplug > event, all good. now cable has link loss or a different cable is put > on the wan port - this should trigger a restart - but this is already > possible with netifd? I just have to write a vtun netifd proto wrapper > I guess. the way it works is that you can hook up a trigger to an interface in uci. you will then get trigger events when said interface is up/down. in this case you would not use the wan but the tunnel interface. in turn the tunnel interface would be triggered by the wan interface adding a vtun netifd proto handler would still be pretty cool as it makes your vtun support far more solid than relying on hacked up script code. i'll have a chat with felix today on how to implement the runwhen stuff in the best way. runit feature set is already supported by using the ubus service api as far as i can tell > >> anything else that you are missing inside procd ? those features should >> be trivial to implement. > > I can't think of anything that is missing in procd at the moment. I'm > offline for the next week(s), so I can't test/work sorry! > There is this subjective thing through: I think runit/daemontools are > great and if procd could have something like runsvdir that would be a > good thing. It enables all kinds of cool stuff e.g. something better > than cron would be nice and runit and runwhen are a pretty cool > solution to this problem (https://wiki.uberspace.de/system:runwhen - > german) - but that's not the job of procd - but if such functionality > would be possible with procd I'm all for it. I can also see why it's > probably not going to happen because the design is quite different and > these usecases are rather exotic and not straight forward. > please create a bullet list of the feature provided by the daemons mentioned above that you are missing in current procd/lede setups. > so far, > regards > Martin > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
