CC @bcmills @matloob

On the one hand, if you want fine-grained control over signal propagation you can always use go build and then execute the resulting binary. Moreover, it's usually a bad idea to send SIGKILL to any individual process (compare #50436) — that does tend to orphan any subprocesses, and the use of subprocesses should essentially always be an implementation detail.

On the other hand, it would be nice to preserve the PID presented to the parent when invoking go run anyway. If someone wants to do the work to make this happen (along with good integration tests for it), I think we could reasonably make the time to review the changes.

Compare #40467.

Half-related, but if the logic for go run changes, I'd appreciate it changing for the golang.org/dl executables too; see #36976.

I just ran into this issue, trying to send interrupts, sigterm, and sigkill to a child process that was being run via "go run" and no signals were being handled by my program which was unexpected.

Also I would orphan my programs and it wasn't easy to understand why this was happening.

I guess, the point of writing this comment is to give an Anecdote from the point of view of a regular, run of the mill, user.

Recently, I also met this issue when developing vercel serverless function with golang runtime and vercel dev.

vercel dev only kills the go run process, and left /tmp/go-buildxxx/xxx/exec/<binary> as orphan, but it still keeps all the resources like opened files and database connections.

I think maybe it's better to patch on vercel side to bypass this situation. 🙈