[LEDE-DEV] [OpenWrt-Devel] Any interest in adding runit to OpenWRT?

[John Crispin]

On 28/12/2016 01:16, Martin Tippmann wrote:
> On Tue, Dec 27, 2016 at 9:43 AM, John Crispin <john at 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
>