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

[Denys Vlasenko]

Hi Felix,

On Sat, Dec 3, 2016 at 4:30 PM, Felix Fietkau <nbd at nbd.name> wrote:
> On 2016-12-03 14:05, Denys Vlasenko wrote:
>> I noticed that ntpd is running on my 15.05.1,
>> but its output goes to /dev/null!
>>
>> I noticed this because ntpd lost sync,
>> but it was not possible to see it because its output
>> (which contains this information) is discarded.
>> I could only see it by stracing the running process.
>>
>> Well, we certainly can fix the ntpd start scritps,
>> but this is a generic problem, right? We'd want ANY
>> daemons to be run "properly", with their output logged.
>> With log size and location controlled. With log rotation.
>> Etc. etc etc.
>>
>> I propose to use runit tools for this.
>> It is a daemontools clone.
>> If you never heard about any of this stuff, please read
>> the entire email (there is a README at the end).
>>
>> For openwrt, this can be particularly easy, since runit
>> is ported to busybox already many years ago. It only needs
>> to be enabled at build time, and started at boot.
>>
>> Thee is no need to migrate all daemons en mass to be run under runit.
>> We can try it with, say, ntpd first. If it goes well, we'd use it
>> for more and more things. If it goes badly, we drom it.
>>
>> Thoughts?
>
> Here's the thing: OpenWrt/LEDE is starting services via procd.
> This is a rather essential piece of how we're dealing with system-wide
> reloading of configuration and automatically restarting/reloading only
> services which are affected by configuration changes.
> In comparison, dealing with logging is rather trivial.
>
> Because of that, I think switching to runit is not a good trade-off.

I see.

To be entirely honest, my request was a probe whether
OpenWRT could have any interest in using runsvdir.

It looks like you have your own tool and it works well for you,
so your answer is "no, not really interested".

I wouldn't even try to pressure you on this :D,
just wanted to explain why I'm talking about it at all.

In Linux world, there is still a need to have a "better init",
since SysV init is ancient and inadequate, and systemd,
while getting a large share of the "market",
is nevertheless not universally liked.

In my humble opinion, for distros which can't use systemd because
of the size, or won't use systemd because they don't like it,
a good contender is daemontools or one of its clones.
It is especially suited for a distros which target smaller systems,
because of its minimalistic and "Unix-like" design.

What daemontools-like clones lacked all these years is not
some technical problem, but lack of concerted effort from
their authors to push for its adoption.
(The very existence of the clones, for example, stems from DJB's
stupid licensing policy. Not a good way to have your tools
widely used... but I digress.)

I decided to try to do what I can, and put together a draft
of the proposal how daemontools-like supervision
should be used by a distro in a way which makes
developers/packagers life easier - they will not need
to target a specific distro, all distros will have common API
for installing and controlling services. It is here:

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

If you have comments about this text, please share them.