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

Martin Tippmann martin.tippmann at gmail.com
Tue Dec 27 19:16:34 EST 2016

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!

> * 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.

> 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.

so far,
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list