glib: disable use of close_range by spawn #112473
Conversation
|
Although this timed out during dependent testing, as expected |
|
Linux-specific failures were all pre-existing, and mostly because of the missing |
|
Importantly, we're not seeing any of the permissions failures we previously saw before, so this does seem like a good workaround for this until the Docker bug is fixed. |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
|
Why didn't we pursue this? |
|
@danielnachun can you also link the docker upstream issue tracker in here? |
|
rebased to the latest master and kicked a new run |
|
For reference, these two issues at least are directly relevant: The long term solution that has not been merged yet is the second one which will by default return ENOSYS (which means the call is not available) when a syscall isn't yet supported by Docker's The reason this will fix these kinds of problems is that I believe the current blocker to merging that is that there are some syscalls which are blocked for security reasons by default even if they are supported by |
So the problem is not Docker but the seccomp installation on the host? Is this only reproducible on linux-self-hosted-1? I can fix that to use 22.04. |
It would be worth trying that, I didn't realize that we hadn't upgraded our host image there to 22.04. Do we know if that is the real bare metal host OS? My worry here is that it goes all way down to the bare metal host and I don't know if we can control that. But it would be fantastic if that fixed this! |
|
One important thing I just noticed based on this discussion - if you are using |
|
Let's try running other I think there are still some other self-hosted failures that are unrelated to this which would be nice to clean up. At the least some look SIMD related, but the self-hosted is now using Zen CPU which seems like it would be sufficient (previously I think I saw Broadwell or some similar Intel CPU). |
|
We should try it with the other |
|
At least in some other PRs, the errors that looked related to this (e.g. errors like We will need to wait for long timeout slot to run other |
|
So this PR can probably be closed. |
|
Yes, huge thanks for @Bo98 for noticing that the host image for our self-hosted runner was still 20.04. We'll need to add in our documentation that the host image for the self-hosted runner must be the same Ubuntu version or newer of the CI image we run inside of it. |
brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew test <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingbrew install --build-from-source <formula>)? If this is a new formula, does it passbrew audit --new <formula>?I was looking more into the usage of
close_rangebygliband noticed that it is only used by gspawn, and its usage is gated by theHAVE_CLOSE_RANGEmacro there. This is done becauseclose_rangewas only recently added toglibcso many systems still don't support it. The code gracefully falls back to using older less elegant methods whenclose_rangeis unavailable (see https://gitlab.gnome.org/GNOME/glib/-/issues/2580).I've confirmed through local testing that
webkitgtk, which reproducibly fails because theclose_rangesyscall is blocked in Docker, builds with no issues onceglibhas been rebuilt with this patch. To test this, I have added a temporary revision bump towebkitgtkso it is rebuilt. This should tell us if the fix worked as it should fail if it didn't.