Looks like we're (fairly consistently) hitting cleanup errors from arm64 and cgroup2. In both cases, Jenkins is complaining about files from TestBuildUserNamespaceValidateCapabilitiesAreV2;
Both arm64 and cgroup2 jobs in Jenkins are running on Jenkins agent with Kernel 5.11 (also see #42892), so it seems there's a relation with that update of the agents / kernel.
https://ci-next.docker.com/public/job/moby/job/PR-42835/19/execution/node/398/
Also: java.nio.file.AccessDeniedException: /home/ubuntu/workspace/moby_PR-42835/bundles/test-integration/TestBuildUserNamespaceValidateCapabilitiesAreV2/de3b5140cc048/root/overlay2/9b312dec55e10fe243a5e0422a7f9375c0cc2880d41696ac19fd6d9c191f1f56-init/work/work
https://ci-next.docker.com/public/job/moby/job/PR-42835/19/execution/node/420/
Also: java.nio.file.AccessDeniedException: /home/ubuntu/workspace/moby_PR-42835/bundles/test-integration/TestBuildUserNamespaceValidateCapabilitiesAreV2/d4b91bdaf46b5/root/165536.165536/overlay2/d6050e82750d178c5151ec1427a44ce8352d9aa6e9843d61483e0f54b4a3125f-init/work/work
Interesting case is that in the arm64 case, the path looks to be a rootless / remapped path (root/165536.165536), whereas in the overlay2 case, the path does not have the remapped user.
I guess that could be explained because the test starts to separate daemons; one rootless, and one not;
|
dUserRemap := daemon.New(t) |
|
dUserRemap.Start(t, "--userns-remap", "default") |
|
ctx := context.Background() |
|
clientUserRemap := dUserRemap.NewClientT(t) |
|
dNoUserRemap := daemon.New(t) |
|
dNoUserRemap.Start(t) |
|
defer dNoUserRemap.Stop(t) |
Wondering if one of those daemons is not succesfully killed, and therefore causing the permission denied
Looks like we're (fairly consistently) hitting cleanup errors from arm64 and cgroup2. In both cases, Jenkins is complaining about files from
TestBuildUserNamespaceValidateCapabilitiesAreV2;Both
arm64andcgroup2jobs in Jenkins are running on Jenkins agent with Kernel 5.11 (also see #42892), so it seems there's a relation with that update of the agents / kernel.https://ci-next.docker.com/public/job/moby/job/PR-42835/19/execution/node/398/
https://ci-next.docker.com/public/job/moby/job/PR-42835/19/execution/node/420/
Interesting case is that in the
arm64case, the path looks to be a rootless / remapped path (root/165536.165536), whereas in theoverlay2case, the path does not have the remapped user.I guess that could be explained because the test starts to separate daemons; one rootless, and one not;
moby/integration/build/build_userns_linux_test.go
Lines 39 to 42 in 085c6a9
moby/integration/build/build_userns_linux_test.go
Lines 90 to 92 in 085c6a9
Wondering if one of those daemons is not succesfully killed, and therefore causing the permission denied