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.

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

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?

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

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.

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