Thanks for reporting this.

I doubt this is related to #12815. This look yet another variant of #30698. We already try to detect Kernel configurations that would make the test fail (CL 166460, CL 180877) but the current checks are possibly not exhaustive.

Also, please note that this is not a build failure (i.e.: the code does not compile). The package compiles just fine, this is just a test failing. You can run make.bash instead of all.bash and the toolchain should be built without errors.

this is what we run...

        set -ex; \
                cd src; \
                export PATH="$(GOROOT)/bin:$$PATH"; \
                eval "$$(go tool dist env)"; \
                bash run.bash -k -no-rebuild;

interesting this fails also in pbuilder chroot configuration...

I can provide information if needed! Such as kernel configuration (Ubuntu 18.04 amd64 default one),
and steps to reproduce on a clean debian/ubuntu environment

I can provide information if needed! Such as kernel configuration (Ubuntu 18.04 amd64 default one), and steps to reproduce on a clean debian/ubuntu environment

@LocutusOfBorg Yes please. It'll help with the investigation. Thanks.

on a Debian/Ubuntu system (I'm using ubuntu 18.04 LTS amd64)

pbuilder-dist sid create
pbuilder-dist sid login (remember the directory where the chroot is extracted)
pull-debian-source golang-1.13

copy the downloaded files into the chroot

go inside the chroot (the login command above does it)
cd golang-*
apt build-dep ../golang*dsc
dpkg-buildpackage

enjoy your failure!

Of course, inside the chroot you can install/play with whatever you want, install git, download stuff and so on...

inside an Ubuntu/Debian machine you probably just need to install "ubuntu-dev-tools"

This is my default kernel configuration

config-5.0.0-25-generic.txt

This also fails on launchpad (see https://launchpadlibrarian.net/440240117/buildlog_ubuntu-xenial-amd64.golang-1.13_1.13-1longsleep1+xenial_BUILDING.txt.gz for example)

Change https://golang.org/cl/195738 mentions this issue: syscall: skip TestAmbientCapsUserns if user namespaces are not supported

@LocutusOfBorg @longsleep Could you please check whether https://golang.org/cl/195738 fixes the test failure for you?

Hello, looks like still failing...

 ok strings 0.272s
ok sync 0.513s
ok sync/atomic 0.077s
--- FAIL: TestAmbientCapsUserns (0.02s)
    exec_linux_test.go:672: fork/exec /tmp/gotest797948891: operation not permitted
FAIL
FAIL syscall 0.142s
ok testing 0.098s

In my case, the kernel is 5.3, so the patch is not skipping the test...

FWIW we have new systemd 241, so maybe /tmp is not able anymore to fork processes?
e.g. now builders have sticky bit in /tmp

Thanks for the feedback @LocutusOfBorg. Reopening the issue for further investigation.

Trying the instructions in #34015 (comment) I was able to reproduce this in a chroot. I think we need to check in TestAmbientCapsUserns whether we're chrooted like it is already done for all other tests involving user namespaces, see the comment here:

@LocutusOfBorg do you only see the issue inside a chroot or also outside?

Change https://golang.org/cl/196500 mentions this issue: syscall: extend skip criteria for TestAmbientCapsUserns

@tklauser only inside chroots, Ubuntu builders can't build outside.

In my machine, and local builds are good

@LocutusOfBorg thanks for confirming. Thus considering this fixed by https://golang.org/cl/196500 which skips TestAmbientCapsUserns in case of the test running in a chroot.

thanks!
I'll happily drop my patch on the next upstream release...
unfortunately that commit doesn't apply on top of the official 1.13 version, so I'll wait for the next tarball :)

Hello, we had a few golang 1.13 releases since 20 September, but none including this patch...

@LocutusOfBorg we generally don't backport fixes to tests to minor releases.

See: https://github.com/golang/go/wiki/MinorReleases