Re: runsvdir polling

From: <>
Date: Sun, 26 Feb 2017 12:17:16 -0800

After some more investigation the problem has gone away. I suspect operator error. Specifically the runsvdir CPU usage was likely caused by a misconfigured service that was generating frequent readproctitle messages. Oops. Current CPU time is about 58s over 28 days uptime which seems fine.

On Tue, Feb 21, 2017 at 11:15:05AM +0100, Martin "eto" Misuth wrote:
> So instead of patching runit, have you considered approaching problem other
> way around: modifying your void boot sequence to boot into s6?

With my discovery that the CPU problem was my error my motivation to patch or switch is decreased. The one remaining small issue is nesting runsvdir but I'm not going to worry about that for now.

> I use void as well, but I am quite unorganized person, so I haven't got very
> far in using s6-svscan on void as PID1 yet. For now, I use runit to supervise s6
> supervision trees, on personal box, at least.
> It seems to me that all that would be needed is wrapping runit's stage1&2
> scripts by execline wrappers, to bring machine up and down and to reuse distro
> provided scripts at the same time. s6 service tree should be probably separate
> from runit one, most runit services should be "copyable" over into s6 though.
> But considering you are competent admin, one would expect you are modifying
> most runit run scripts anyway.
> Of course there might be some hidden gotchas.
> Anyway, I guess, that sharing such work, might end up (hopefully) beneficial to
> more people in void community, interested in using s6 instead of runit. At
> least, I would be interested in being able to use s6-svscan as PID1 on void.
> What are you thoughts on this?
> eto

It doesn't sound too difficult but staying close to upstream makes it less work to track their changes. I also like that enough people use Void that the stock bits are unlikely to be broken when I update. My next project is to try out their mkimage tool and get a RPi + my code build process going.
Received on Sun Feb 26 2017 - 20:17:16 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC