Re: small proxy
On Tue, May 30, 2017 at 07:27:09PM +0100, Jorge Almeida wrote: > On Tue, May 30, 2017 at 7:01 PM, <39066...@gmail.com> wrote: > > On Tue, May 23, 2017 at 01:07:13PM +0100, Jorge Almeida wrote: > >> Is there any small proxy that is supervision-friendly? > > > > Polipo is no longer maintained but overall quite nice. Good support for > > pipelining etc. > > Well, the author doesn't seem very enthusiastic about it :) > > I was kind of hoping that someone with the musl/dietlibc/... mindset > would have written something of the kind, but I guess it's not the > case... > > Thanks > > Jorge The Polipo author's reasoning may apply to your application as well, my memory is essentially the value of HTTP proxies has declined a lot now that so much of the web is behind HTTPS.
Re: small proxy
On Tue, May 23, 2017 at 01:07:13PM +0100, Jorge Almeida wrote: > Is there any small proxy that is supervision-friendly? Polipo is no longer maintained but overall quite nice. Good support for pipelining etc.
Re: runsvdir polling
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.
Re: runsvdir polling
On Sat, Jan 14, 2017 at 04:10:07PM -0500, Steve Litt wrote: > On Fri, 13 Jan 2017 21:12:27 -0800 > 39066...@gmail.com wrote: > > > I'm using runit as my primary init on Linux to good effect but have > > noticed that it accumulates CPU time even while the system is idle. I > > How much time in how much uptime? Which process are you looking at with > this accumulated time? Here's what I get: runsvdir has used 1m 55s over a bit under 5 days. The runsv instances are way less (but then they have no reason to wake). Load average is 0.00. > On my computer, none of this in any practical way affects my computing. > I would guess on a more heavily used computer, any deleterious effects > of runit time consumption could be solved by running runsvdir and all > the runsv's with a positive nice value. > > In my opinion, by far the greatest benefit of runit is its simplicity, > and there's no way I'd trade that for a theoretical efficiency benefit. That sounds sensible on a desktop. In my case the motivation is to trim a source of power draw for an image that's going to run on a battery-powered device that will be awake but idle a lot of the time. Why Linux? Pretty much familiarity & tooling, if power is ok then I get to have my cake and eat it too.
runsvdir polling
I'm using runit as my primary init on Linux to good effect but have noticed that it accumulates CPU time even while the system is idle. I suspect that this is a consequence of runsvdir polling the service directory for changes and that using inotify would reduce this. This would introduce some complexity and variance between platforms but bring the benefit of removing a source of CPU wake-ups. Has using inotify been considered and rejected for another reason?
