syscall: TestUnshare failure

[belka-ew]

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

go version go1.7.1 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/tmp/SBo/package-google-go-lang/usr/lib64/go1.7.1/go"
GOTOOLDIR="/tmp/SBo/package-google-go-lang/usr/lib64/go1.7.1/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build222919198=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

(it is slackware linux 14.2)

What did you do?

go test -c syscall
./syscall.test

What did you expect to see?

PASS

What did you see instead?

--- FAIL: TestUnshare (0.01s)
exec_linux_test.go:182: Expected 3 lines of output, got 7
FAIL

One test fails on one of my machines, but the error seems to be unrelated to #16283 and #17206 .

It seems to happen because the output from "/proc/net/dev" is too long. There is the output on my server, where the test fails (on my slackware home pc, I don't have this problem):

# cat /proc/net/dev

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
    lo: 594936327  167759    0    0    0     0          0         0 594936327  167759    0    0    0     0       0          0
ip6_vti0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
ip6tnl0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
ip6gre0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth1: 34263091  192644    0    0    0     0          0         1 194343254  215239    0    0    0     0       0          0
  eth0: 3542031   53880    0    0    0     0          0       141 122958691  103226    0    0    0     0       0          0

[quentinmit]

The contents of /proc/net/dev outside the test aren't super relevant here; because we're passing Unshareflags: syscall.CLONE_NEWNET, we're requesting a new network namespace from the kernel. The cat process should be run in a new network namespace that only has an lo interface.

Is there anything special about your server? I notice that we are already skipping this test on Kubernetes. I would expect if the clone() syscall fails that the test would fail with "Cmd failed" and not the error you saw.

[belka-ew]

Hm, not much special. It is mostrly mail and webserver; ipv6 enabled; It is also in a local network behind vpn appliance.
I don't know what information I can provide, so if you need something special, I'll help as much as I can.

Here is the output from the test if it can be useful.

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
    lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
ip6_vti0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
ip6tnl0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
ip6gre0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

[quentinmit]

When I asked "is there anything special", I was wondering if it's virtualized in any way. It's odd that GOROOT is inside /tmp - are you using a package manager to run the Go tests? Is it possible that it's running the test under fakeroot and fakeroot is lying about the unshare call?

[belka-ew]

Oh, sorry for my misunderstanding. No, I'm not running any virtual machines or similar.
The tests were started from the script that creates an installation package, but that script is a simple shell-script that creates a pseudo-hierarchy under /tmp (usr, usr/lib and so on) and packages everything then in a gzipped tar archive (.tgz). It doesn't use chroot or something else as far as I can see. You can find the script here: https://slackbuilds.org/slackbuilds/14.2/development/google-go-lang/google-go-lang.SlackBuild
I run it with
RUN_TEST=true sh ./google-go-lang.SlackBuild

and on one system it fails, on another one not.

And also after installation, I have the test installed under /usr/lib64/go1.7.1/go/src/syscall/exec_linux_test.go and if I run (as root)

$ echo $GOROOT
/usr/lib64/go1.7.1/go

$ go test -c syscall
$ ./syscall.test

I get the same error

[quentinmit]

So, I tried two different Slackware machines, one on GCE and one on VirtualBox, and neither showed any interfaces other than "lo". I don't know what's special about your configuration on your machine that you get extra interfaces, but I do think since eth0 goes away that the unshare call is working.

I'm going to propose that we change the test to only verify that the # of interfaces decreases, which should indicate that the unshare call did something. I'll send a CL off in a moment.

[gopherbot]

CL https://golang.org/cl/30372 mentions this issue.