Zombies won't be reaped if spawn() throws in Configuration.run

[jakepetroules]

Under certain circumstances if spawn() throws in Configuration.run, process resources will never be freed (zombies won't be reaped on Unix) if the call to spawn() throws an error after posix_spawn or fork/exec has successfully returned a pid.

This "resource leak" doesn't affect Windows because the only point at which spawnDirect/spawnAsUser can throw after a successful process creation explicitly releases the handles if closing file handles fails, but the process may still continue running.

On Unix (both Darwin and non-Darwin implementations are affected), failing to close file handles after a successful spawn, or failing to access the working directory, can trigger this bug. In this case we should probably SIGKILL the process and perform termination monitoring to wait for exit.

A good way to do this could be to remove Execution from SpawnResult and then change the return type of spawn to something like Result<(Execution, SpawnResult), (Execution?, Error)> (where the Execution nullability indicates whether the failure occurred pre- or post- spawn of the actual process) while turning spawn into a non-throwing function.

[iCharlesHu]

I believe his issue only affects Linux and only under specific scenarios:

On Darwin, we use posix_spawn(). posix_spawn() is the last step in spawn(), and if it succeeds, spawn() will succeed. According to the posix_spawn() man page:

Upon successful completion, posix_spawn() and posix_spawnp() place
the PID of the child process in pid and return 0. If there is an
error during the fork() step, then no child is created, the
contents of *pid are unspecified, and these functions return an
error number as described below.

(see https://man7.org/linux/man-pages/man3/posix_spawn.3.html)

posix_spawn is "atomic" in the sense that if it does not return zero (spawn() throws), no child is created, so we won't need to reap.

On Linux: this issue happens if fork() succeeds (child created) but any setup code fails between fork and exec (including exec() itself). I'll add a Linux-specific handler for this.