On 27/12/2016 01:07, Martin Tippmann wrote:
> On Mon, Dec 26, 2016 at 5:32 PM, Rob Landley <r...@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.
>
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.
* allow hotplug events to trigger service restart/reload
anything else that you are missing inside procd ? those features should
be trivial to implement.
John
> 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
> _______________________________________________
> openwrt-devel mailing list
> openwrt-de...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
