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.
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-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.