Terminating `zig build run` does not terminate child processes

[MadLittleMods]

Zig Version

0.13.0

Steps to Reproduce and Observed Behavior

1. Using the standard zig init boilerplate
2. Write a little program that keeps running and doesn't exit:
   src/main.zig

   const std = @import("std");
   
   pub fn main() void {
       while (true) {
           std.log.info("Hello, World!", .{});
           std.time.sleep(1 * std.time.ns_per_s);
       }
   }

3. zig build run
4. Notice the three processes that have spawned (the original zig build run, the expanded zig build, and running the final binary)

   $ ps aux | grep zig
   USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   eric     3972336  0.0  0.0 434540 35328 pts/21   Sl+  01:20   0:00 zig build run
   eric     3972354  0.0  0.0 282024  2816 pts/21   Sl+  01:20   0:00 /home/eric/Documents/code/zig/random/kill-build-hello-world-test/.zig-cache/o/cdb0a375ac43b8fc9e3e09e439f80b53/build /home/eric/zig/0.13.0/files/zig /home/eric/Documents/code/zig/random/kill-build-hello-world-test /home/eric/Documents/code/zig/random/kill-build-hello-world-test/.zig-cache /home/eric/.cache/zig --seed 0x4ec1d056 -Z148e1dbdd164c915 run
   eric     3972408  0.0  0.0   1064   512 pts/21   S+   01:20   0:00 /home/eric/Documents/code/zig/random/kill-build-hello-world-test/zig-out/bin/kill-build-hello-world-test

5. Kill the zig build run parent process (kill 3972336)
6. Notice that the program keeps running and outputting text
7. If you instead kill the main binary (kill 3972408), all of the processes are cleaned up

---

Also tested with the latest master (0.14.0-dev.655+d30d37e35)

Expected Behavior

My expected/desired behavior is that when killing the zig build run process, all of the child processes are cleaned up (no orphaned child processes).

Note: There is no automatic propagation of signals (SIGTERM or otherwise) to children in the process tree so the behavior is as expected in POSIX land. We would need to add our own signal handlers to make this work.

Related issue: #18340

---

My personal use case is wanting to use zig build run in a child process runner. The only thing I can access there is child.kill() or child.id (process ID) so I'm unable to clean up all of the processes unless I split the build from running the binary.

test "run and kill main process" {
   const allocator = std.testing.allocator;

   const main_argv = [_][]const u8{ "zig", "build", "run" };
   var main_process = std.process.Child.init(&main_argv, allocator);
   // Prevent writing to `stdout` so the test runner doesn't hang,
   // see https://github.com/ziglang/zig/issues/15091
   main_process.stdin_behavior = .Ignore;
   main_process.stdout_behavior = .Ignore;
   main_process.stderr_behavior = .Ignore;

   try main_process.spawn();

   std.time.sleep(3 * std.time.ns_per_s);

   const main_term = try main_process.kill();
   // std.debug.print("main_process.id {}", .{main_process.id});

   try std.testing.expectEqual(std.process.Child.Term{ .Signal = std.posix.SIG.TERM }, main_term);
}

[matklad]

That's a hard problem in general, and I believe no actually good solution exists on Unix. Things I sadly know about the issue, in case it is helpful to anyone:

• On Unix, if you kill the process by ^Cing it in the shell, the shell itself takes care of cleaning the whole process tree (this is to make pipelines work). If you kill the process in any other way, then stuff leaks

• On windows, there's an actually working solution using job objects: https://github.com/rust-lang/cargo/blob/6c9bccc64968e2212c093186aa75c82b74ebb5e5/src/cargo/util/job.rs

• You could "fix" it on unix by making zig build process session leader, but that breaks ^C in the shell, so the cure is worse than the disease.

• Useful background info is here: https://github.com/oconnor663/duct.py/blob/master/gotchas.md#killing-grandchild-processes

• In cooperative scenarios (where you control both the parent and the child), I always solve this by setting child's stdin to a pipe in the parent, and writing some code in the child to kill itself if its stdin is closed. This is nicely cross platform.

• For uncooperative scenarios on Linux, I solved it by wrapping the whole thing into unshare:

  unshare --user -f --pid ./zig/zig build -Drelease scripts -- cfo
  

Isn't systems programming wonderful!