-
Notifications
You must be signed in to change notification settings - Fork 146
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
docker pull on certain images fail on bionic with docker 18.09 #451
Comments
Thanks for filing the issue @Sid-Sun. I haven't been able to reproduce it so far, but will try again in a different node with a similar kernel version -- I'm running 5.11 in my current setup:
|
Hi @Sid-Sun,
Please repeat this with the
then attach the resulting strace output. Thanks! |
Hey! Thanks for the quick response, here is the strace with forks follow @rodnymolina That's interesting... I will try to update the kernel on one of the nodes and try to reproduce it thanks :D |
Thanks @Sid-Sun, that was helpful though I still don't see the root cause. Here is what I see:
With all of this, I am suspecting this is a Docker error (i.e., it's epolling a regular file), and the fact that you don't see it with later versions of Docker would seem to add weight to this. I certainly can't see how it could be related to Sysbox. Do you know if this occurs outside of a Sysbox container (e.g., when using the same version of Docker on a regular host)? Also, it may be worthwhile getting the same strace with Docker 19.03 pulling the same image, so we can compare. Finally, on a quick web search, it seems it may be related to this Stack Overflow post, tracked by this Moby issue. That would explain it since Sysbox containers are always rootless. |
Hi @ctalledo, I've run a few more tests to get some more data points; on both native (VMs) and sysbox environments. What I have observed is:
Docker 19 and above:
It appears there is some sort of incompatibility between docker 18, sysbox and kernel 5.4 - swapping any one of these seems to resolve the incompatibility Note: Docker 18 is not available for focal out of the box, i had to use docker's bionic archive to install it You can find the strace of the tests I ran here |
Hi @Sid-Sun, thanks for the excellent data points. Based on the fact that with Docker 18 the "polling xterm" error is always present, yet sometimes the pull fails and sometimes it doesn't, it seems to me that error is a red-herring. This also gels with my observation that this error occurs much earlier in the strace than the failure point. However the weird thing is that there is no other EPERM error in the strace that would give us a better hint on why the pull fails. I think I'll need to repro on my side to dig down further. Let me ask: how important is that you use Docker 18? (wondering how high I need to prioritize this). Thanks again. |
Hi, we've moved to a newer docker version, I guess it would be best to note some potential incompatibility in the documentation until this is nailed down |
Thanks @Sid-Sun ; I think this issue is probably the best way to document the problem (until we are able to better understand the underlying root cause). |
Closing for now, please re-open if this occurs again. |
When running docker 18.09.7 on Ubuntu Bionic, certain image pulls fail with:
failed to register layer: Error processing tar file(exit status 1): operation not permitted
the issue does not occur with docker versions 19.03 or higher on bionic
the issue also cannot be reproduced on all docker images, only certain layers in some images seem to fail, we have been able to consistently reproduce with
rrdockerhub/ros-base-melodic-amd64:latest
might be similar to #254
Environment Details:
5.4.0-1053-gke
Complete output:
strace:
Posted here
When we initially identified the issue, strace had:
However it might have been due to something else, we were using a different image at the time. Using a cleaner image directly from nestybox and only setting specific docker version gets rid of this
Dockerfile used to create the image (same as nestybox modified to specify docker version):
Pod spec:
Thanks :D
The text was updated successfully, but these errors were encountered: