Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syscall: TestUnshare failure #17224

Closed
belka-ew opened this issue Sep 25, 2016 · 6 comments
Closed

syscall: TestUnshare failure #17224

belka-ew opened this issue Sep 25, 2016 · 6 comments

Comments

@belka-ew
Copy link

@belka-ew belka-ew commented Sep 25, 2016

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
Copy link
Contributor

@quentinmit quentinmit commented Oct 3, 2016

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.

@quentinmit quentinmit added this to the Go1.8 milestone Oct 3, 2016
@quentinmit quentinmit changed the title TestUnshare /proc/net/dev syscall: TestUnshare failure Oct 3, 2016
@belka-ew
Copy link
Author

@belka-ew belka-ew commented Oct 3, 2016

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
Copy link
Contributor

@quentinmit quentinmit commented Oct 3, 2016

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
Copy link
Author

@belka-ew belka-ew commented Oct 4, 2016

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
Copy link
Contributor

@quentinmit quentinmit commented Oct 5, 2016

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
Copy link

@gopherbot gopherbot commented Oct 5, 2016

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

@gopherbot gopherbot closed this in cb986de Oct 5, 2016
@golang golang locked and limited conversation to collaborators Oct 5, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.