On Tue, Dec 27, 2016 at 1:07 AM, Martin Tippmann <martin.tippm...@gmail.com> 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! > > 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. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
