cmd/cover: cover uses /tmp but ubuntu 22.04 Firefox now won't access /tmp

[jlearman]

Go version

go version go1.21.11 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/jlearman/.cache/go-build'
GOENV='/home/jlearman/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/jlearman/.gvm/pkgsets/go1.21.11/global/pkg/mod'
GONOPROXY='github.ibm.com'
GONOSUMDB='github.ibm.com'
GOOS='linux'
GOPATH='/home/jlearman/.gvm/pkgsets/go1.21.11/global'
GOPRIVATE='github.ibm.com'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/jlearman/.gvm/gos/go1.21.11'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/jlearman/.gvm/gos/go1.21.11/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.11'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/jlearman/ws/gw-control-skupper/go.mod'
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 -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1595630815=/tmp/go-build -gno-record-gcc-switches'

What did you do?

go tool cover -html=c.out

What did you see happen?

The command opens Firefox, and Firefox reports that it can't access the file, because on Ubuntu 22.04, Firefox is now a snap package, and thus runs in a sandbox without access to /tmp.

What did you expect to see?

I expected to see the coverage report displayed in the browser.

The coverage report HTML file should be put in the user's tmp directory. If it doesn't exist, the user should be prompted to create it. In addition, there should be an environment variable to override the location, and this should be documented for go tool cover

[cagedmantis]

cc @thanm

[thanm]

Thanks for the report @jlearman .

I note that this seems to work for me:

$ TMPDIR=/x/y/z go tool cover -html=foo.p
$

Is this an option for your workflow?

[gabyhelp]

Related Issues and Documentation

• cmd/go: go 1.22.0: go test throws errors when processing folders not listed in coverpkg argument #65653 (closed)
• cmd/cover: support -mod and other build flags #35869
• cmd/go: `-x` output with `test -cover` contains wrong path for some files under cwd #23982 (closed)
• cmd/cover: ignores os.Create error #17951 (closed)
• cmd/go: test / tool cover: uncomfortable colors on html page with coverage results #37796 (closed)
• cmd/go: test -coverpkg=./... fails to change working directory #33016 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[jlearman]

Thanks for the report @jlearman .

I note that this seems to work for me:

$ TMPDIR=/x/y/z go tool cover -html=foo.p
$

Is this an option for your workflow?

Thanks. My workaround was to reinstall Firefox without snap, so this isn't an issue for me.

[thanm]

OK. It doesn't look as though there are any changes needed to Go here, closing out this issue.

[jlearman]

I disagree. You should fix the tool to actually work on a very popular Linux distribution like Ubuntu. Go shouldn't force many users to waste time investigating and then use some strange workaround in order to use a tool.

[ianlancetaylor]

Setting TMPDIR is very standard on Unix systems. I'm surprised that Ubuntu is shipping an approach that does not permit access to /tmp and also does not set TMPDIR. How do they expect programs to find the temporary directory to use?

[jlearman]

It's also raised as a snapd issue (plus the issue that Ubuntu decided to switch Firefox from apt to snap -- and if you install using apt you still get the snap.)

See https://bugs.launchpad.net/snapd/+bug/1972762 for a snapd issue. There are many reports of problems with snap Firefox dating back to 2022, but it doesn't look like they'll be fixed.

[ianlancetaylor]

From Go's point of view I have no idea what we can do to avoid this problem.

[jlearman]

One solution would be to not use /tmp -- instead use $HOME/tmp (and if it doesn't exist, prompt the user.)

Another option would be to document the issue (possibly adding it to -help output) with suggestions such as setting TMPDIR, for cases where the browser can't access /tmp. For exampe:

In cases where browsers can't access the system temporary directory such as /tmp on Linux, set the TMPDIR environment variable to an alternate location.