Thanks for the clarification regarding using the heap vs leaking. I know sinit doesn't respawn processes which is why I was talking about some supervisor similar to s6-supervisor but without opendir() to supervise s6-svscan. After reading your reply I see that it's all a non-issue. I will use s6-svscan as process 1.
Thanks! On Fri, Feb 10, 2017 at 11:41 PM, Laurent Bercot < [email protected]> wrote: > I've been studying the documentation of S6. I see that s6-svscan has been >> designed so that it can run as init (PID==1), and there's a note that most >> opendir() implementations use malloc, so it may be possible to leak >> memory. >> > > No, that's not what I wrote. > I wrote that s6-svscan will never leak memory, and I stand by it. > I also wrote is that it's impossible to guarantee that s6-svscan does > not use heap memory at all, because opendir() uses heap memory. But it > does not mean it leaks it. > > Unless, of course, the libc manages to botch opendir/readdir/closedir, > but those are simple functions and I don't know of a libc that does not > get them right. > > > To protect against this I'm pondering to use suckless init (sinit) as PID >> 1, and have it spawn something supervising s6-svscan. My understanding is >> that sinit won't be able to leak memory in userspace. >> > > Don't. sinit is not a correct init: it does not supervise any process. > If you kill -9 -1, then exit your shell, sinit is unable to give you back > a way of recovering your system and you have effectively bricked it - and > need a hard, physical reboot (and your filesystems will be dirty). > > > If a suitable sinit -> supervisor -> s6-svscan chain could be made, it >> takes a little extra memory and boot-up time, but should mean that if >> opendir() leaks memory an s6-svscan dies, then the leaked memory will be >> recovered and the supervisor could restart s6-svscan. >> > > sinit will not respawn s6-svscan if it dies. > Check it: http://git.suckless.org/sinit/tree/sinit.c > > > I think it would be worth the trade-off of always using a little extra >> resources to get the extra protection. Does it seem wise? Am I overlooking >> things or misunderstanding things? >> >> If it makes a difference I plan to use musl libc. >> > > If you are looking to get theoretical correctness, sinit is not what you > want anymore than s6-svscan. Even runit is not (it assumes that you want > to start stage 3 as soon as stage 2 dies, even if it crashed). > > If you are looking to get a working system, you will have no problem > using s6-svscan as process 1, because there will be no memory leak. > If you are using musl, it's easy to check: > http://git.musl-libc.org/cgit/musl/tree/src/dirent/opendir.c > http://git.musl-libc.org/cgit/musl/tree/src/dirent/readdir.c > http://git.musl-libc.org/cgit/musl/tree/src/dirent/closedir.c > > So: don't worry, be happy. > > -- > Laurent > >
