The author said something that is technically correct but I feel gives the wrong impression to us folks who may be trying to solve the "kill all child processes" problem. There is a simple bash one-liner to ensure child processes are killed that doesn't require root and it's using one of their examples of a process leak:
The author doesn't share this example because "user namespaces introduce a number of quirks, such as breaking gdb (by breaking ptrace), so they also can't be used by most users". I disagree that the container/unshare approach can't be used by most users. So strace works just fine on my machine and gdb is able to attach and print a backtrace. Now it's true that gdb itself prints out a warning when I do this:
warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable. Connect to gdbserver inside the container.
So:
- user namespaces do solve the "kill all child processes" problem
- strace still works
- gdb from outside the namespace isn't fully supported
So if you wanted to debug a child subprocess with gdb you'd presumably have to invoke gdb via unshare so it shared the same pid namespace (not tested).
Sending SIGKILL to `unshare` reparents the inner process `sleep infinity` to my computer's top-level systemd, where it continues to run (process leak).
So not sure how that ensures "child processes are killed".
I added the `--kill-child` flag to unshare because Linux did not offer a reliable way to kill child processes when pressing the "Cancel build" button in my CI pipeline.
With the above, SIGKILL against `unshare` will reliably tear it down and everything below it.
But Ctrl+C still has no effect, and SIGTERM against `unshare` still has no effect.
So I agree with the post author that the Linux process API is unreliable. This stuff should be easy.
- user namespaces do solve the "kill all child processes" problem
- strace still works
- gdb from outside the namespace isn't fully supported
So if you wanted to debug a child subprocess with gdb you'd presumably have to invoke gdb via unshare so it shared the same pid namespace (not tested).