-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
syscall: TestGroupCleanupUserNamespace failure on linux-s390x-ibm #52088
Comments
Change https://go.dev/cl/397316 mentions this issue: |
Thanks @bcmills for fixing this. I was adding a new builder on Thurs which caused the failure only when run from systemd. I've figured out how to reproduce the error locally on the new builder so I can confirm it fixes the problem. The new builder is at a newer version of RHEL 8 but I haven't figured out why the selinux info is different on the old builders vs new new one. All have selinux enabled and are run from systemd. Could this be backported to 1.18 and 1.17 so those branches will also be fixed? Would older release branches need it as well or are they guaranteed not to be built anymore? If it can't be backported everywhere its needed I'll probably disable selinux because I don't think I'll find a fix. |
@gopherbot, please backport to Go 1.17 and 1.18. This is a test-only fix for an issue exposed by a builder upgrade. |
Backport issue(s) opened: #52148 (for 1.17), #52149 (for 1.18). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
We won't need to backport to branches before 1.17 because they're no longer running tests. It's ultimately up to the release team to decide on the 1.17 and 1.18 backports but TBH I think it's a shoo-in. |
Change https://go.dev/cl/398234 mentions this issue: |
Change https://go.dev/cl/398235 mentions this issue: |
…upUserNamespace “If you have a procedure with ten parameters, you probably missed some.” ― attr. Alan J. Perlis I argue that the same is true for hard-coded special cases. In TestGroupCleanupUserNamespace, instead of a curated list of strings observed in the wild we now check for a prefix, as was done for TestGroupCleanup in CL 24670. Updates #52088. Fixes #52149. Change-Id: I59c5b0c048113e306996c0f8247e09c714d2423a Reviewed-on: https://go-review.googlesource.com/c/go/+/397316 Trust: Bryan Mills <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> (cherry picked from commit 434b2a5) Reviewed-on: https://go-review.googlesource.com/c/go/+/398234 Reviewed-by: Russ Cox <[email protected]>
…upUserNamespace “If you have a procedure with ten parameters, you probably missed some.” ― attr. Alan J. Perlis I argue that the same is true for hard-coded special cases. In TestGroupCleanupUserNamespace, instead of a curated list of strings observed in the wild we now check for a prefix, as was done for TestGroupCleanup in CL 24670. Updates #52088. Fixes #52148. Change-Id: I59c5b0c048113e306996c0f8247e09c714d2423a Reviewed-on: https://go-review.googlesource.com/c/go/+/397316 Trust: Bryan Mills <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> (cherry picked from commit 434b2a5) Reviewed-on: https://go-review.googlesource.com/c/go/+/398235 Reviewed-by: Ian Lance Taylor <[email protected]>
greplogs --dashboard -md -l -e 'FAIL: TestGroupCleanupUserNamespace'
2022-03-31T20:02:55-f990b0f/linux-s390x-ibm
This test is empirically fragile and non-portable: it has broken (and had to be updated) in at least #16224, #16303, #19938, #34547, and #46752. With that many hard-coded special cases, it is all but certain that we have missed some.
It isn't clear to me from reading the test what property it is actually testing or what invariants it expects (it is quite sparse on commentary). Given the empirical fragility of the test, and given that the
syscall
package is essentially frozen at this point anyway, I suggest that we delete the test outright. Barring that, if someone feels strongly enough about keeping the test to make it more robust, perhaps it would be reasonable for the test to actually parse the output string, strip thecontext
field, and ensure that the groups in the reported list are all identical tonobody
ornogroup
.The text was updated successfully, but these errors were encountered: