4 ms·
lxc-attach: see https://news.ycombinator.com/item?id=7258242 https://news.ycombinator.com/item?id=7258242 about why I think SSH is more appropriate. Zombies: t
by FooBarWidget 13y ago
lxc-attach: see https://news.ycombinator.com/item?id=7258242 https://news.ycombinator.com/item?id=7258242 about why I think SSH is more appropriate.
Zombies: this is not about child processes created by the program. It's about child processes created by child processes! For example what if your app spawns another app that daemonizes by double forking? Your PID 1 has to reap all adopted child processes, not just the ones it spawned.
- zimbatm 13y agoThen it's a bug in the child process. Turtles all the way down. Also, double-forking is a hack that should burn in hell. EDIT to the reply below: It's still a design issue but I agree that it's not always practical to change existing software. A small PID1 wrapper that reaps zombie processes and execs the target program would be a good middle-ground.
- FooBarWidget 13y agoIt's not. Most apps rightfully expect that they're not PID 1, and that the real PID 1 takes care of that sort of stuff. Only in a container does it happen often that your totally-not-designed-to-be-a-PID-1 app, actually is PID 1. What if you're creating a PostgreSQL container, and your init script spawns a daemon, after which it exec()s the PostgreSQL server process as PID 1? The daemon then spawns a few processes that fork a few times. PostgreSQL only waitpid()s on its own postmaster worker processes and so those other processes become zombies. Are you telling me that PostgreSQL is broken and that you have to patch PostgreSQL? I think using a proper init system, and running PostgreSQL under it, is a much saner view on things. The small wrapper that you mentioned is exactly the /sbin/my_init provided by baseimage-docker.