I will look into it!

On Mon, Jun 13, 2016 at 12:12 PM Austin Clements notifications@github.com
wrote:

TestUnshare has been failing 22% of the time on the mips64le builder since
May 20th. The most recent failure is
https://build.golang.org/log/3bcf1e559a0fe0e05f036f425912a59b99aeeda3.
This was probably the fault of commit 1ded9fd
1ded9fd:
"syscall: fix unshare test on mips", though maybe that just exposed an
existing bug.

$ greplogs -dashboard -l -E '/bin/cat: invalid' | findflakes -dir ~/.cache/fetchlogs/rev -paths
First observed be1b930 20 May 14:36 2016 (202 commits ago)
Last observed 5701174 13 Jun 14:05 2016 (0 commits ago)
100% chance failure is still happening
22% failure probability (45 of 203 commits)
Likely culprits:
22% be1b930 reflect: hide unexported methods that do not satisfy interfaces
17% b3bf2e7 net/http: update bundled http2
13% 1ded9fd syscall: fix unshare test on mips
10% 16f846a net/http: update bundled http2
8% 9cd2c70 net: deflake TestDialTimeoutMaxDuration
6% 8527b8e syscall: add Unshare flags to SysProcAttr on Linux
5% 448246a cmd/compile: don't exit early because of hidden error messages
4% dc4427f context: make DeadlineExceeded have a Timeout method
3% 0b80659 net/http/httptest: restore historic ResponseRecorder.HeaderMap behavior
2% 3b50adb build: unset GOBIN during build
No known past failures

/cc @cherrymui https://github.com/cherrymui @jfrazelle
https://github.com/jfrazelle

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16056, or mute the thread
https://github.com/notifications/unsubscribe/ABYNbFN9fMMD3oiIk0VboaPAOK-NZXspks5qLauqgaJpZM4I0pDw
.

To clarify, this test is actually not flaky. The builder tasks are scheduled onto three machines, two of which do not run with root, so this test is skipped there. I just ran it on these two machines manually with root, it constantly passes on one machine while constantly fails on the other.

strace on the failure machine shows

# strace -f ./syscall.test -test.v -test.run=Unshare
...
[pid 17296] unshare(CLONE_NEWNET)       = -1 EINVAL (Invalid argument)
...

Maybe kernel configuration (The machines may have different kernel configurations)? Is there something I can check?

It seems it is CONFIG_NET_NS? The passing machine does have this enabled while the failure machine doesn't. I'll recompile the kernel on that machine.

If the test fails when some kernel configuration is missing, then we should check that and skip the test when it won't pass. We shouldn't rely on Go users recompiling their kernel in order to pass a test.

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