os/signal: TestTerminalSignal failures with `subprogram failed: exit status 1` after `Waiting for exit...`

[gopherbot]

#!watchflakes
post <- pkg == "os/signal" && test == "TestTerminalSignal" && `Waiting for exit` && `subprogram failed: exit status 1`

Issue created automatically to collect these failures.

Example (log):

error running second subprocess: <nil>
--- FAIL: TestTerminalSignal (90.76s)
    signal_cgo_test.go:186: Sending ^Z...
    signal_cgo_test.go:198: Sending SIGCONT...
    signal_cgo_test.go:211: Waiting for exit...
    signal_cgo_test.go:214: subprogram failed: exit status 1

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
default <- pkg == "os/signal" && test == "TestTerminalSignal"

2023-07-26 15:13 darwin-amd64-12_0 go@f0894a00 os/signal.TestTerminalSignal (log)

error running second subprocess: <nil>
--- FAIL: TestTerminalSignal (90.76s)
    signal_cgo_test.go:186: Sending ^Z...
    signal_cgo_test.go:198: Sending SIGCONT...
    signal_cgo_test.go:211: Waiting for exit...
    signal_cgo_test.go:214: subprogram failed: exit status 1

— watchflakes

[bcmills]

See previously:

• os/signal: TestTerminalSignal failures with subprogram failed: signal: killed #57418
• os/signal: TestTerminalSignal failures on Darwin builders #37329

But the failure mode here is different. (Possibly related to the macOS cluster in #54461 (comment)?)

[bcmills]

This does look like a possible match for the timeout failures in #37329 (comment), though. 🤔

[bcmills]

@mknyszek, note that the failures in #37329 (comment) were all on the darwin-amd64-12_0 builder.

It is possible that this is a kernel bug in that specific macOS release. If that appears to be the case, you may want to consider adding a skip for the test based on the OS or kernel version, or (less ideally but perhaps easier to implement) based on testenv.Builder() != "darwin-amd64-12_0".