Go version

go version go1.23.0 darwin/arm64

Output of go env in your module/workspace:

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

What did you do?

I ran the following test code, expecting it to terminate the command as intended

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
	defer cancel()

	if err := exec.CommandContext(ctx, "sleep", "5").Run(); err != nil {
		fmt.Println(err)
	}
}

What did you see happen?

In fact, it did terminate the command, but the returned error was signal: killed. I don't think this is the correct error output.

What did you expect to see?

I believe it should return "context canceled,". Every developer clearly understands that the lifecycle of this command is managed by their own context, and the command would terminate due to the cancel of the context derived from their Go program.

However, "signal: killed" is an unexpected error, and it can be triggered for various reasons. This error makes the lifecycle management of the command unclear (at least to me). I'm not even sure why the command was terminated—maybe it was due to an OOM kill? Or perhaps it was manually terminated by the user? I might need to check the system logs to confirm this.

The relevant code can be found at

From the comments, I understand this is an expected error handling behavior. Should we revisit this behavior based on the points above for further discussion?