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

[Martin Tippmann]

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!
>
> This implies that systemd should also be an option. As long as there's
> no standard init in the distro, might as well do them all? (Seems
> counterproductive to me.)

Hi, I'm not a dev and I just shared my personal 'would be nice to
have' opinion. I appreciate the work on procd and netifd and ubus and
a lot of thought went into it and it serves almost all usecases pretty
well.

afaik (please correct me if I'm wrong) systemd has some properties
that make it a bad fit for something like a 32mb/4mb flash router:

- glibc only (i.e. you are on your own with musl, good luck, patches
not welcome)
- hard dbus dependency (maybe bus1 in the future might make this
obsolete). dbus depends on glibc, glib? all 'huge' deps for a small
router.
- udev is mandatory?
- cgroups are mandatory? (+some other kernel stuff that is off by
default on LEDE/OpenWRT)
- <lot's of other stuff>

I don't see any benefits and we have almost everything systemd does
with procd,netifd,ubus

Adding runit+runsvdir to a squashfs image are a few kb at best - last
time I checked the image size didn't even change.

Some practical example where runit might be useful (if you know how to
do this with procd, please tell me :)

- 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
- 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 don't need systemd. This might be useful for bigger machines like
some NAS devices where the users are familiar with systemd but IMHO
procd+netifd+ubus are superior in every aspect to systemd for these
low end router use cases.

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.

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.

But it's IMHO a path worth going because it provides a unixy, sane,
ressource-efficient, powerful interface without politics.


just my <amount> cents
Martin