Sysv heavyweight?
It's got a reasonable amount of stuff in it. The Debian version of sysvinit (v2.88) is about 10,000 lines of C code. Probably not a huge deal, but it does more than just reaping zombie processes, if that's really all you want.
Docker and the PID 1 zombie reaping problem
11–20 of 72 posts
Re: Docker and the PID 1 zombie reaping problem
#12Sysv heavyweight?
Compared to solutions like runit, it is.
Re: Docker and the PID 1 zombie reaping problem
#13This is nice and all, but the way the authors wrote this article gives off this feeling of hubris that they've uncovered some critical yet technically obscure problem. They haven't. This is Unix programming 101 right here. Even if the Docker community has been generally ignorant of this, the problem is not any less glaring or basic. I'm not sure if my_init is really an "init system", though. I'd call it an "init daem…
Author of the article here. Of course it's a basic Unix programming 101... from our points of view! You and I think it's basic because we're so knowledgeable in this area. But this does not hold for the rest of the world. 99 out of 100 people that I've spoken to have absolutely no idea about this problem. I used to link to the Wikipedia article and thought that people would get it. They didn't. People started getting it once I gave 15 minute talks about the problem and describing things with diagrams. Lots of people gave me the suggestion that I should blog about it, and so I did.
Re: Docker and the PID 1 zombie reaping problem
#14Is there a ticket in the docker project? I would like to follow the progress on this one.
Everything I could find was this ticket: https://github.com/docker/docker/issues/5305
Re: Docker and the PID 1 zombie reaping problem
#15Isn't this effectively a non-issue? It's literally just a tiny entry in a table that is held no? Or does it just cause Docker to behave oddly?
There are two issues. First is Murphey's law. 1 zombie process is probably harmless, but if the amount grows then you'll fill up kernel limits and the container cannot create further processes. Second, zombie processes that don't go away can also interfere with software that check for the existence of processes. For example, [the Phusion Passenger application server]( https://www.phusionpassenger.com/ ) manages proce…
Fair enough!
Re: Docker and the PID 1 zombie reaping problem
#16Surely writing a minimal init in C (or Go if you like) is better than using Python... it is not a lot of code, and frankly I would trust it not to die and kill your container more. Plus Python has a chunk of dependencies you don't need in a minimal container.
Lots of system tools are written in Python nowadays. If you use a Debian, Ubuntu or CentOS base image then there's a good chance that Python is preinstalled because some system tool depends on it. It was also much easier to write the tool in Python than in C. Writing it in C would have taken much longer, and at the end of the day we wanted to get work done instead of worrying about a few MBs, which only take 1 second…
It really does not need much code in C, here is a simple init https://github.com/arachsys/init/blob/master/init.c for example.
In particular you want to avoid memory allocation so it cannot fail even in low memory situations, which you cannot guarantee with Python. That means you might die reaping children with low memory which would kill your container.
Re: Docker and the PID 1 zombie reaping problem
#17Isn't this effectively a non-issue? It's literally just a tiny entry in a table that is held no? Or does it just cause Docker to behave oddly?
There are two issues. First is Murphey's law. 1 zombie process is probably harmless, but if the amount grows then you'll fill up kernel limits and the container cannot create further processes. Second, zombie processes that don't go away can also interfere with software that check for the existence of processes. For example, [the Phusion Passenger application server]( https://www.phusionpassenger.com/ ) manages proce…
> Crash detection is implemented by parsing the output of `ps`
Would there be anything to be gained by actually rooting around in /proc yourselves, rather than relying on ps?
Re: Docker and the PID 1 zombie reaping problem
#18Why write your own mini-init instead of using something like supervisord?
Re: Docker and the PID 1 zombie reaping problem
#19This is nice and all, but the way the authors wrote this article gives off this feeling of hubris that they've uncovered some critical yet technically obscure problem. They haven't. This is Unix programming 101 right here. Even if the Docker community has been generally ignorant of this, the problem is not any less glaring or basic. I'm not sure if my_init is really an "init system", though. I'd call it an "init daem…
Author of the article here. Of course it's a basic Unix programming 101... from our points of view! You and I think it's basic because we're so knowledgeable in this area. But this does not hold for the rest of the world. 99 out of 100 people that I've spoken to have absolutely no idea about this problem. I used to link to the Wikipedia article and thought that people would get it. They didn't. People started getting…
There is no relative point of view here. This is simply an egregious educational failure where application developers have failed to understand the underpinnings of how their platform handles processes at a high level.
Then again, this is how the industry works, I suppose. You rediscover an old paradigm or basic property of your system that has been abstracted out, present it as new, deliver it in a shiny package and reap the fame.
Sorry, I was mostly ticked at how you presented this issue in such an alarmist and "problem-reaction-solution" tone. It's just humorous.
Re: Docker and the PID 1 zombie reaping problem
#20Earlier quoted context omitted.
There are two issues. First is Murphey's law. 1 zombie process is probably harmless, but if the amount grows then you'll fill up kernel limits and the container cannot create further processes. Second, zombie processes that don't go away can also interfere with software that check for the existence of processes. For example, [the Phusion Passenger application server]( https://www.phusionpassenger.com/ ) manages proce…
> Crash detection is implemented by parsing the output of `ps` Would there be anything to be gained by actually rooting around in /proc yourselves, rather than relying on ps?
Ps is implemented by parsing /proc, so the results you get are the same.
Having said that, /proc/xxx/status does contain a flag that tells you whether a process is a zombie or not. So on Linux, Phusion Passenger parses that file as an extra check. But not all software does this.