os/signal: Notify leaks a goroutine

[inancgumus]

What version of Go are you using (go version)?

$ go version
go1.18.1 darwin/arm64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/inanc/Library/Caches/go-build"
GOENV="/Users/inanc/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/inanc/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/inanc/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m4/qbbxcxxx2h3b_ydm_6j6vhr40000gn/T/go-build3719417202=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

https://go.dev/play/p/Y6Lq4oaMSoi

What did you expect to see?

No leaked goroutine.

What did you see instead?

A goroutine leak:

panic: err

goroutine 1 [running]:
main.main()
        /Users/inanc/.../main.go:17 +0x90

goroutine 33 [syscall]:
os/signal.signal_recv()
        /usr/local/go/src/runtime/sigqueue.go:148 +0x30
os/signal.loop()
        /usr/local/go/src/os/signal/signal_unix.go:23 +0x20
created by os/signal.Notify.func1.1
        /usr/local/go/src/os/signal/signal.go:151 +0x30
exit status 2

I don't know whether this is intentional or not. Is there a way to prevent this leakage?

This previous issue might be related to this one: #21576

[ianlancetaylor]

This is working as designed and intended. We could add a mechanism to shut down that goroutine when no more signals are being handled, but very few programs would ever execute that code path, and even fewer would care about the extra goroutine. It doesn't seem worth it.

[inancgumus]

Thanks, @ianlancetaylor. Glad to hear that it's intentional.