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 <
ska-supervision_at_skarnet.org> 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
>
>
Received on Sat Feb 11 2017 - 02:34:22 UTC