Jochen Sprickerhof <jspri...@debian.org> writes:
> containerd uses sysctl during the build which fails as a normal user: > > === RUN TestLinuxSandboxContainerSpec > sandbox_run_linux_test.go:241: TestCase "spec should reflect original > config" > sandbox_run_linux_test.go:71: Check PodSandbox annotations > sandbox_run_linux_test.go:124: > Error Trace: > /<<PKGBUILDDIR>>/_build/src/github.com/containerd/containerd/pkg/cri/server/sandbox_run_linux_test.go:124 > > /<<PKGBUILDDIR>>/_build/src/github.com/containerd/containerd/pkg/cri/server/sandbox_run_linux_test.go:259 > Error: "" does not contain "0 2147483647" > Test: TestLinuxSandboxContainerSpec > sandbox_run_linux_test.go:241: TestCase "host namespace" > sandbox_run_linux_test.go:71: Check PodSandbox annotations > sandbox_run_linux_test.go:241: TestCase "should set supplemental groups > correctly" > sandbox_run_linux_test.go:71: Check PodSandbox annotations > sandbox_run_linux_test.go:241: TestCase "should overwrite default sysctls" > sandbox_run_linux_test.go:71: Check PodSandbox annotations > sandbox_run_linux_test.go:241: TestCase "sandbox sizing annotations > should be set if LinuxContainerResources were provided" > sandbox_run_linux_test.go:71: Check PodSandbox annotations > sandbox_run_linux_test.go:241: TestCase "sandbox sizing annotations > should not be set if LinuxContainerResources were not provided" > sandbox_run_linux_test.go:71: Check PodSandbox annotations > sandbox_run_linux_test.go:241: TestCase "sandbox sizing annotations are > zero if the resources are set to 0" > sandbox_run_linux_test.go:71: Check PodSandbox annotations > --- FAIL: TestLinuxSandboxContainerSpec (0.00s) > > https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/pkg/cri/server/sandbox_run_linux_test.go#L124 Are you sure that the test is actually executing a sysctl(2) command? Looking at the code, it seems to me that this is code is assembling a runtime spec that the CRI implementation will then carry out. Forthermore, the output above indicates that the assertion on line 123 actually holds, but the one on line 124 does not: https://sources.debian.org/src/containerd/1.6.24~ds1-1/pkg/cri/server/sandbox_run_linux_test.go/#L124 The cause for this is most likely in https://sources.debian.org/src/containerd/1.6.24~ds1-1/pkg/cri/server/sandbox_run_linux.go/#L147. Here the code is explicitly checking whether it is running in in a usernamespace, which is exactly what 'unshare' is doing. > This make the build fail for example in the sbuild unshare backend. Well, technically the build of the code succeeds, but the tests don't run in a usernamespace. Arguably, the test could be updated to skip this assertion if running in a user namespace. Can you please help me understand whether, and if so since when, we have the requirement that all packages must be buildable inside a usernamespace and where was this announced to be release-critical? (CC'ed debian-release for input). I'm inclined to downgrade this bug to severity "normal" or "wishlist". If that really needs to be fixed, I could imagine to either disable the test, or change the test to skip that assertion if running inside a user namespace. I would recommend forwarding this as a bug to upsream to see how relevant running the containerd testsuite is in a user namespace. This feels like a rather fringe/niche use-case anyways. Best, -rt
