Maybe there is a way to get this to work if there's a way to get the parent's process group ID? Not sure.

As discussed on Discord, I believe this should actually just be kill 0 for all platforms. AFAICT kill $PPID only works on linux because of the sandbox (that causes the command to fail with an error which set -e causes the builder to exit, and presumably that causes the pid namespace to get torn down), xargs does not proactively kill its spawned processes when it dies.

If you do use kill 0, that signals the entire process group, which is going to include the shell itself since it's a non-interactive shell (which means job control defaults to off). If you want just the xargs process tree to shut down you can enable job control first with set -m, that way the xargs pipeline will be its own process group and the kill 0 will only affect it, at which point bash's set -e behavior will take over. So doing this really just depends on whether there's any benefits to log output (or whether Nix cares at all about whether the builder exits with a code or a signal).

AFAICT kill $PPID only works on linux because of the sandbox

This would match the issue with the memory stats job that I observed and also bisected down to the Linux sandbox. Fun.

Thanks, I’ll give that a shot. I don’t think we want to set -m at least without somehow explicitly detecting whether the xargs pipeline was killed or not (which I’m not sure is possible?).

set -m just enables job control monitor mode, which makes every pipeline get its own process group (and bash will print a line when background jobs exit). It shouldn't actually hurt anything, it just makes bash behave a bit more like interactive mode. and you can presumably turn it off again after the xargs finishes if you like.

I'm not sure what you mean about explicitly detecting whether the xargs pipeline was killed? If job control is enabled, the kill 0 will just kill xargs (and seq if it hasn't already finished) and its child processes, and bash will treat that as an error and exit (due to set -e). If you want to intercept that, you can wrap the xargs pipeline in an if or add a || after and test the status code (and a code over 128 indicates a signal, where the signal number is the exit status minus 128, e.g. SIGTERM is 143). But normal errexit behavior should be fine here? It's what you get with kill $PPID already.

This isn't going to work if anyone adds another background job later on, since the jobspec here is evaluated at EXIT time instead of right now.

Also I just want to point out that stdenv installs a default exit handler that this overwrites. That may not matter at all, if nothing installs a failureHook or exitHook, but if you want to preserve that you could switch this over to adding both a failureHook and exitHook (or just a failureHook and adding an explicit kill after the xargs finishes).