4 ms·

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

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: unshare -U --map-user=$(id -u) --map-group=$(id -g) -f -p sh -c '{ sleep inf &} &' 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).

user3939382 4y ago
> There is a simple bash one-liner… > unshare -U --map-user=$(id -u) --map-group=$(id -g) -f -p sh -c '{ sleep inf &} &'
- deleted 4y ago
  [deleted]
nh2 4y ago
This does not work for me, at least not in the way most people would expect it to. When I run: > unshare -U "--map-user=$(id -u)" "--map-group=$(id -g)" -f -p sh -c 'command sleep infinity' then Ctrl+C has no effect. Sending SIGTERM to `unshare` has no effect. 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". You need at least the `--kill-child` flag: > unshare -Ufp --kill-child -- bash -c "command sleep infinity" See https://unix.stackexchange.com/questions/393210/why-does-unshare-based-killing-only-work-reliably-with-fork/393279#393279 https://unix.stackexchange.com/questions/393210/why-does-uns... 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.

user3939382 4y ago

> There is a simple bash one-liner… > unshare -U --map-user=$(id -u) --map-group=$(id -g) -f -p sh -c '{ sleep inf &} &'

deleted 4y ago
[deleted]

nh2 4y ago

This does not work for me, at least not in the way most people would expect it to. When I run: > unshare -U "--map-user=$(id -u)" "--map-group=$(id -g)" -f -p sh -c 'command sleep infinity' then Ctrl+C has no effect. Sending SIGTERM to `unshare` has no effect. 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". You need at least the `--kill-child` flag: > unshare -Ufp --kill-child -- bash -c "command sleep infinity" See https://unix.stackexchange.com/questions/393210/why-does-unshare-based-killing-only-work-reliably-with-fork/393279#393279 https://unix.stackexchange.com/questions/393210/why-does-uns... 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.