cmd/go: run does not relay signals to child process

[myitcv]

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

$ go version
go version devel +71218dbc40 Wed Jul 22 21:31:19 2020 +0000 linux/amd64

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="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build722565624=/tmp/go-build -gno-record-gcc-switches"

What did you do?

# This will correctly exit
exec go run parent.go build

# This will block
exec go run parent.go


-- parent.go --
package main

import (
	"bufio"
	"io"
	"io/ioutil"
	"log"
	"os"
	"os/exec"
	"path/filepath"
)

func main() {
	var cmdArgs []string

	if len(os.Args) == 2 && os.Args[1] == "build" {
		td, err := ioutil.TempDir("", "")
		if err != nil {
			log.Fatalf("failed to create temp dir: %v", err)
		}
		defer os.RemoveAll(td)
		out := filepath.Join(td, "child")
		build := exec.Command("go", "build", "-o", out, "child.go")
		if out, err := build.CombinedOutput(); err != nil {
			log.Fatalf("failed to run [%v]: %v\n%s", build, err, out)
		}
		cmdArgs = []string{out}
	} else {
		cmdArgs = []string{"go", "run", "child.go"}
	}

	r, w := io.Pipe()

	done := make(chan struct{})
	child := exec.Command(cmdArgs[0], cmdArgs[1:]...)
	child.Stdout = w

	if err := child.Start(); err != nil {
		log.Fatalf("failed to start child [%v]: %v", child, err)
	}

	go func() {
		if err := child.Wait(); err != nil {
			log.Fatalf("child process [%v] failed: %v", child, err)
		}
		close(done)
	}()

	// Continue once we have read the first line
	if _, _, err := bufio.NewReader(r).ReadLine(); err != nil {
		log.Fatalf("failed to read start line from child: %v", err)
	}

	if err := child.Process.Signal(os.Interrupt); err != nil {
		log.Fatalf("failed to notify child process")
	}

	<-done
}
-- child.go --
package main

import (
	"fmt"
	"os"
	"os/signal"
)

func main() {
	sigint := make(chan os.Signal, 1)
	signal.Notify(sigint, os.Interrupt)
	fmt.Println("Started")
	<-sigint
}

What did you expect to see?

The interrupt signal to be passed to the child process by go run, I think?

What did you see instead?

The go run child process does not relay the interrupt signal to the child process.

cc @bcmills @jayconrod @matloob

[tie]

This issue seems to be related to my case.

main.go

package main

import (
	"log"
	"os"
	"os/signal"
	"time"
)

func main() {
	log.SetFlags(0)

	sigs := make(chan os.Signal, 1)
	signal.Notify(sigs, os.Interrupt)

	log.Println("awaiting signal")
	<-sigs

	log.Println("sleeping")
	time.Sleep(time.Second * 5)

	log.Println("exiting")
}

go get golang.org/dl/gotip
gotip download

Running and sending interrupt, the following works as expected:

% export GOROOT="$HOME"/sdk/gotip
% "$GOROOT"/bin/go run main.go
awaiting signal
^Csleeping
exiting
% 

But this exits before the child process:

% gotip run main.go 
awaiting signal
^Csleeping

% exiting

[zikaeroh]

@tie That's probably related to or the same as #36976, as the golang.org/dl tree's go<..> run doesn't handle signals the same way as the regular tooling.

Otherwise my understanding (based on trying to fix #36976) is that go run ends up forwarding all signals to the child process, but handles the ones that exit the process in the parent by ignoring them (but the forwarding should pass them down anyway).

It'd be nice if all of these would re-exec their binaries rather than running them as children on OSs that supported it, as that'd eliminate all of these for most users. Though perhaps that's not doable if go run needs to clean up the temporary binary.

[matthewmueller]

I'm running into the same thing. Here's a slightly reduced reproduction:

child/main.go

package main

import (
	"fmt"
	"os"
	"os/signal"
)

func main() {
	ch := make(chan os.Signal, 1)
	signal.Notify(ch, os.Interrupt)
	<-ch
	fmt.Println("got sigint")
}

main.go

package main

import (
	"fmt"
	"log"
	"os"
	"os/exec"
	"path/filepath"
	"time"
)

func main() {
	if err := run(); err != nil {
		log.Fatal(err)
	}
}

func run() error {
	cmd := exec.Command("go", "run", filepath.Join("child", "main.go"))
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	if err := cmd.Start(); err != nil {
		return err
	}
	time.Sleep(1 * time.Second)
	fmt.Println("interrupting")
	if err := cmd.Process.Signal(os.Interrupt); err != nil {
		return err
	}
	fmt.Println("interrupted")
	return cmd.Wait()
}

If you run the following command:

$ go run scripts/test-go-run/main.go
interrupting
interrupted

It will hang at cmd.Wait(), despite sending the interrupt signal. It does work if you kill the process with os.Kill instead of os.Interrupt.

[bcmills]

cmd/go ignores SIGINT and SIGQUIT here:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/base/signal.go;l=19-23;drc=10240b9d6b39cd7edc6566d0875a4b6499bcd9b3

Probably something about that needs to change in order to propagate those two signals in particular during go run.

[mitar]

cmd/go ignores SIGINT and SIGQUIT here

It does not completely ignore it. It closes Interrupted channel which makes it later on when it exits on its own exit with the exit code 1. I am really confused by this design. So my current workaround was to make a process group and send INT signal to the whole process group so that the child process cleanly exits (with exit code 0), but this particular behavior means that go run still exits with non-zero exit code. So not just that it does not pass signals, it also masks if the child processes exited with zero or non-zero exit code. (I know that it does not pass the exact exit code of the children, but I was assuming that at least zero/non-zero state is passed.)