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

[Denys Vlasenko]

On Tue, Dec 27, 2016 at 1:07 AM, Martin Tippmann
<martin.tippmann at gmail.com> wrote:
> On Mon, Dec 26, 2016 at 5:32 PM, Rob Landley <rob at landley.net> wrote:
>> On 12/26/2016 08:05 AM, Martin Tippmann wrote:
>>> On Sun, Dec 25, 2016 at 9:01 PM, Denys Vlasenko
>>> So TL;DR: procd is fine for init but having runit/runsvdir easily
>>> usable would be a nice feature to have!
>
> Some practical example where runit might be useful (if you know how to
> do this with procd, please tell me :)

These are my examples

https://git.busybox.net/busybox/tree/examples/var_service

The README there explains how these are used to configure network.

Now that you mentioned netifd, I googled it up and it seems
my runit scripts managed to do something rather similar.

> - we have on our mesh network a VPN client (vtun) that starts when wan
> is up (via hotplug) but connectivity to the mesh network depends on
> olsr working.
> - at the moment there is some cumbersome cron logic shellscript hell
> that tries to check that a) vtun is working, b) olsr is working

Like
https://git.busybox.net/busybox/tree/examples/var_service/dhcp_if_pinger/run

> - writing a runit sv check script for vtun that checks for the correct
> olsr neighbours and that restarts vtun if no neighbours are found is
> pretty simple with runit. symlink the check for runwhen in the
> /etc/hotplug.d/vtun-wan script and then unlink on ifdown event. runit
> picks up the symlink and does the right thing. So there is the vtun
> connection and the 'sv ./etc/services/vtun check' script that checks
> olsr neighbors
> - This gives you seperation of concerns, it's unixy, it's only shell
> and it's something you can reason about.
>
> So what I'd like to have is something like adding events to runit - if
> netifd realizes there is a link loss on the wan interface I want to
> trigger somewhere sv stop /etc/services/vtun

I do not know how WAN if different from LANs, my needs to detect
ethernet and wifi disconnects are satisfied with this service:

https://git.busybox.net/busybox/tree/examples/var_service/ifplugd_if/run
https://git.busybox.net/busybox/tree/examples/var_service/ifplugd_if/ifplugd_handler

In short, a set of dhcp + wpa_supplicant + ifplugd + vpnc + pppd +
openvpn + ntpd
services under runsv can be made to play very well. I tried it.
Not too difficult.

All is restarted as needed on unplug / replug / loss of wifi / pppd establishing
link, routing and firewalling is reconfigured.

Like NetworkManager, but, you know, without NetworkManager :D

> But marrying runit+ubus+netifd+procd would _really_ solve some real
> world usecases we have in a unixy, reasonable way. I'm open for debate
> and discussion but this would provide a lot of flexibility for a
> rather low cost/overhead - be it memory/flash.

Just for the record, I'm not a runsv zealot.
If procd is good at it too, and if there would be enough
development push behind it so that its use expands from
its current niche to be usable everywhere on Linux, from wristwatches
to routers to desktops to supercomputers, then I'll have no objections.

> Unfortunatly this mail is all talk and no walk and figuring out a sane
> procd/netifd <-> runit interface is some rather hard problem if you
> want a good solution.

So far I don't see a problem needing such interface.

runsvdir/runsv is "just" a service babysitter. Its services
can interface with whatever other programs they need in whatever ways
they find necessary. runsv's will just keep services running
(or stopped, or one-shot, as ordered), they don't do anything else.

The situation looks like people who use procd so far don't see
any pressing need to run yet another service babysitting thing
on their boxes.

I have experience running boxes with runsv,
have no experience with procd, so can't really do a technical
comparison.