Skip to content
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

Hang when saving multiple images to tarball #332

Open
negasora opened this issue Feb 12, 2021 · 0 comments
Open

Hang when saving multiple images to tarball #332

negasora opened this issue Feb 12, 2021 · 0 comments

Comments

@negasora
Copy link

When trying to save multiple tags of an image to one .tar, the process takes 100% cpu and hangs

Works:
img-linux-amd64 save -o images.tar python:3.8.6-alpine

Hangs:
img-linux-amd64 save -o images.tar python:3.8.6-alpine python:3.8.7-alpine

yaraskm added a commit to yaraskm/img that referenced this issue Dec 6, 2021
- The previous method would loop over the image references and try to
save each one. Even if this did work, the tar archive would overwrite
the previous instance on each invocation meaning that the last image
specified on the CLI would be the only one in the archive. Even then,
this method would hang because a filesystem lock was acquired on the
underlying BoltDB during the first invocation of the loop
(within `client.createWorkerOpt(...)`) but never freed. Because of this, every
subsequent call would only hang as seen in genuinetools#332

- This refactor properly passes all image references to the underlying
buildkit type to let it construct the image archive with all references
specified.
yaraskm added a commit to yaraskm/img that referenced this issue Dec 7, 2021
- The previous method would loop over the image references and try to
save each one. Even if this did work, the tar archive would overwrite
the previous instance on each invocation meaning that the last image
specified on the CLI would be the only one in the archive. Even then,
this method would hang because a filesystem lock was acquired on the
underlying BoltDB during the first invocation of the loop
(within `client.createWorkerOpt(...)`) but never freed. Because of this, every
subsequent call would only hang as seen in genuinetools#332

- This refactor properly passes all image references to the underlying
buildkit type to let it construct the image archive with all references
specified.
yaraskm added a commit to yaraskm/img that referenced this issue Dec 8, 2021
- The previous method would loop over the image references and try to
save each one. Even if this did work, the tar archive would overwrite
the previous instance on each invocation meaning that the last image
specified on the CLI would be the only one in the archive. Even then,
this method would hang because a filesystem lock was acquired on the
underlying BoltDB during the first invocation of the loop
(within `client.createWorkerOpt(...)`) but never freed. Because of this, every
subsequent call would only hang as seen in genuinetools#332

- This refactor properly passes all image references to the underlying
buildkit type to let it construct the image archive with all references
specified.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant