Error processing tar file(archive/tar: missed writing 4096 bytes): #777
Comments
|
We are experiencing something similar. The build is ok on dev local envs (recent Debian, Ubuntu) but fails on an old Docker 1.12.1 (Git commit: 23cf638) using OpenJDK 1.8.0_111-b15 and Maven 3.3.9 (jkube k8s maven plugin 1.3.0) on CentOS Linux release 7.2.1511 In this case the build fails with a "Connection reset by peer" obscure message, maybe due to the old docker daemon version that internally logs the archjive/tar error message, but - again - manually sending the tar generated by the plugin to the docker daemon we get the very same error even if the content of the tar seems ok |
|
Is there a way to reproduce the issue so we can further investigate? ? Is the result the same if you load->build the tar using: docker load -i target/docker/path/to/tmp/docker-build.tar |
|
The docker load command fails with
both on the problematic server and in dev local env. At https://github.com/davidecavestro/vagrant-jkube-connection-reset-by-peer I've shared some stuff to reproduce the issue on a vagrant box. |
|
The issue is consistently reproducible from docker-engine 1.12 up to docker-ce 17.12 |
|
So, do you mean this is specific to the environment (Docker version + OS)? i.e. It does work on new versions of Docker ?? I'm checking your vagrant example (:raised_hands: thanks for this). But I had some trouble running that on Fedora, also I think the vagrant file is not provisioning the project files (checking this now in another machine). |
|
The docker version seems to play a role: switching to a docke versionr >=18.06 in the vagrant box the image is built with no issues.
When the box is up and running you could issue a |
I'm running this on Windows, and it doesn't work very well :( What I want to try is to generate the docker-build.tar in the vagrant provisioned machine, and then load that tar to the host machine's docker daemon. I think we might be building a Docker archive that's not compatible with those older Docker versions. There are alternative docker packagings, compression available, this is something else I want to try. |
|
Given a certain version of the jkube plugin, mvn and jdk, I guess the tar generated is the same both within the vagrant box or on the host. I'd say the issue arises from the golang tar library built within the docker binary, i.e. the Flush() function in https://golang.org/src/archive/tar/writer.go |
Yes, this is what I suspect. But there are other considerations such as how access to the Docker daemon is performed. Anyway, I'll try something else to reproduce since the Vagrant option is not working very well.
I'm not following 100% here. Internally we use commons-compress to generate the docker-build.tar archive (https://github.com/eclipse/jkube/blob/120ee60c1217b1bd24cbfbd4cd49ebf876e5f673/jkube-kit/common/src/main/java/org/eclipse/jkube/kit/common/archive/JKubeTarArchiver.java#L53). Is there some specific reason on why you are running older Docker versions? If updating them is not possible, have you tried using |
|
Never tried with jib build strategy here. Great idea, I'll give it a try. |
|
About jib strategy, it builds the image, but fails pushing it to the registry (it's an insecure registry sadly exposed only over HTTP)
That is the same error I get if I issue a curl to the registry using https, while a curl over http or a docker push work, since the registry is listed as an insecure one in docker daemon config. Any clue on how to push to an insecure registry using jib? (creds over http) |
:( Could you open a specific feature request issue for that 🙏 |
|
I have sketched #782 |
|
As a side note, the whole thing works perfectly with fabric8-maven-plugin:3.1.63. |
|
@davidecavestro : that's quite old version of fabric8-maven-plugin. What about newer versions 4.4.1? |
|
Yep, it works even with 4.4.1. |
|
I think in FMP we relied on Maven to generate the tar file. We really need to see the difference of a tar file generated with one plugin and the other. |
|
@davidecavestro : I'm trying to reproduce your issue. I cloned https://github.com/davidecavestro/vagrant-jkube-connection-reset-by-peer adding fabric8-maven-plugin with the same configuration. But When you said it's working with 4.4.1, did you mean this reproducer project or some other project? |
|
Yep, I meant the reproducer project, with the assembly portion modified to |
|
This works with FMP, but introduces changes into the generated Dockerfile and how the temporary structure is packaged into the tar, hence the two tar don't share the same contents. OTOH the vagrant box is meant to give you an old docker that is not able to process the tar from jkube (but accepts the one from fabric8). |
|
@davidecavestro : Thanks a lot for sharing vagrantfile, I can reproduce your issue |
… Docker versions Tar files generated during `k8s:build` were getting rejected from Docker v1.12.1 (API version 1.24). Not setting size of TarArchiveEntry in case of directories seem to fix this issue Signed-off-by: Rohan Kumar <rohaan@redhat.com>
|
I noticed that in case of jkube directory size was more than zero: When I set TarArchiveEntry size only in case of files, I'm able to get jkube working with docker: |
|
For future reference, also note that user/group id, name, etc. are not set in the TarArchiveEntry entities. |
|
Let me create a separate issue for this. |
|
ye, if I build a service that uses the jkube generated dockerfile it works fine. When I build a service that has a dockerfile of its own, everything seems to work ok until I add fileSets to the assembly (possibly pushing the tar over a certain size, I am not sure). If I just add a single file for example to the assembly I am ok. |
|
Maybe there's something wrong with the assembly and the generated file descriptor. |
|
That gets really hard for me to do, I have to sell my soul to the gods of banking before I am allowed to do stuff like that but I will try. |
|
docker-file-provided.zip I have recreated the same project on my private laptop (docker version is 20.10, I cant easily regress that). The problem does not manifest there. I am not surprised though. Its local docker and newer. I suspect this may be related to the size of the tar, if I choose a much smaller jar file in the assembly I dont get the problem. |
|
Hi @manusa, dont suppose there is any way you can find some to check this out for me? I just upgraded to the latest release in the vain hope I might get lucky but the problem persists. Its a real issue for me, I need to bring our organisation up to jkube but there is no way I can do that unless we can get our dockerfile based services working as well. cheers |
|
Sorry, it seems that I didn't get the notification for this issue. |
|
hi @manusa, sorry to ping you again. Have you managed to look at this at all again? |
|
Hi Paul, sorry still no time. I'll reopen the issue and try to allocate some time for us to investigate. |
|
Hi @manusa, sorry to bump this again. Any time to look at all? |
|
Hi @pmbsa |
|
@pmbsa : I'm trying to reproduce your issue in Vagrant box from https://github.com/davidecavestro/vagrant-jkube-connection-reset-by-peer. When I run Were you seeing the same issue with your project? I can confirm for me it's failing in dockerfile mode only. If I add a custom configuration rather than using a dockerfile, I'm able to run |
|
Ye, thats exactly what we see. The docker host seems to reject the tar file or something to that effect.. we uave a fair few docker file based projects that need migrating so i would be super appreciative if you could find a solution. |
…e to zero for directories (eclipse-jkube#777) While fixing tarball issue in eclipse-jkube#793, we had added this `tarEntry.setSize(0L)` in JKubeTarArchiver to fix tarball compatibility with old docker daemons. However, it is set only when the file is not present in `fileModeMap`. In case of Dockerfile based builds, `fileModeMap` seems to contain file modes for different files and directories. Hence, we're not able to set TarEntry size to zero. Move `tarEntry.setSize(0L)` out of fileMode related `if-else` block.
|
@pmbsa : I think this is the same problem we fixed before. We had added this However, in the case of Dockerfile mode directory seems to be present in Moving this out of filemode if-else block seems to fix problem on my vagrant set up: } else if (currentFile.isDirectory()) {
- tarEntry.setSize(0L);
tarEntry.setMode(TarArchiveEntry.DEFAULT_DIR_MODE);
}
+ if (currentFile.isDirectory()) {
+ tarEntry.setSize(0L);
+ } |
…e to zero for directories (eclipse-jkube#777) While fixing tarball issue in eclipse-jkube#793, we had added this `tarEntry.setSize(0L)` in JKubeTarArchiver to fix tarball compatibility with old docker daemons. However, it is set only when the file is not present in `fileModeMap`. In case of Dockerfile based builds, `fileModeMap` seems to contain file modes for different files and directories. Hence, we're not able to set TarEntry size to zero. Move `tarEntry.setSize(0L)` out of fileMode related `if-else` block.
…e to zero for directories (eclipse-jkube#777) While fixing tarball issue in eclipse-jkube#793, we had added this `tarEntry.setSize(0L)` in JKubeTarArchiver to fix tarball compatibility with old docker daemons. However, it is set only when the file is not present in `fileModeMap`. In case of Dockerfile based builds, `fileModeMap` seems to contain file modes for different files and directories. Hence, we're not able to set TarEntry size to zero. Move `tarEntry.setSize(0L)` out of fileMode related `if-else` block.
…e to zero for directories (#777) While fixing tarball issue in #793, we had added this `tarEntry.setSize(0L)` in JKubeTarArchiver to fix tarball compatibility with old docker daemons. However, it is set only when the file is not present in `fileModeMap`. In case of Dockerfile based builds, `fileModeMap` seems to contain file modes for different files and directories. Hence, we're not able to set TarEntry size to zero. Move `tarEntry.setSize(0L)` out of fileMode related `if-else` block.
…e to zero for directories (eclipse-jkube#777) While fixing tarball issue in eclipse-jkube#793, we had added this `tarEntry.setSize(0L)` in JKubeTarArchiver to fix tarball compatibility with old docker daemons. However, it is set only when the file is not present in `fileModeMap`. In case of Dockerfile based builds, `fileModeMap` seems to contain file modes for different files and directories. Hence, we're not able to set TarEntry size to zero. Move `tarEntry.setSize(0L)` out of fileMode related `if-else` block.
|
Good news! That sounds hopeful at least!
…On 24 Jun 2022, 20:32 +0200, Rohan Kumar ***@***.***>, wrote:
@pmbsa : I think this is the same problem we fixed before. We had added this tarEntry.setSize(0L) to set directory tarEntry size to 0.
https://github.com/eclipse/jkube/blob/61345823be63c73cf334649e33e9c5146f9d5f7a/jkube-kit/common/src/main/java/org/eclipse/jkube/kit/common/archive/JKubeTarArchiver.java#L80-L85
However, in the case of Dockerfile mode directory seems to be present in fileModeMap, so we never get into else if block, and directory tarEntry size is not set.
Moving this out of filemode if-else block seems to fix problem on my vagrant set up:
} else if (currentFile.isDirectory()) {
- tarEntry.setSize(0L);
tarEntry.setMode(TarArchiveEntry.DEFAULT_DIR_MODE);
}
+ if (currentFile.isDirectory()) {
+ tarEntry.setSize(0L);
+ }
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Description
The
jkube:buildgoal failes onCentOS Linux release 7.9.2009 (Core)with:The same project is working on Windows.
The TAR file looks fine with
tar -tf docker-build.tar.The image can be built manually by going into the assembly directory and running
docker build .sodockerand thedocker daemonare working.The TAR file is somehow not valid for the
docker daemon:Info
mvn -v) : 3.6.3The text was updated successfully, but these errors were encountered: