You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 27, 2023. It is now read-only.
Is this a request for help?:
Not a request for help, it's more a bug or at best reporting misleading documentation.
Is this a BUG REPORT or a FEATURE REQUEST? (choose one):
BUG REPORT
Version of Anchore Engine and Anchore CLI if applicable:
anchore-cli, version 0.9.3
Engine DB Version: 0.0.15
Engine Code Version: 1.0.0
What happened:
I ran anchore as a container with a read-only filesystem as well as a config.yaml that was setup with a tmp_dir specified to a volume I was mounting to the container instance. My tmp_dir path is setup to be /analysis_scratch. When I attempted to analyze an image after adding it via anchore-cli I got an analysis_failed message. Upon investigating and tailing the anchore-worker.log file, I saw error messages where /tmp was still being used by anchore. The tmp_dir directory is being used, but there is still code in anchore that is using /tmp during the unpacking during analysis it looks like, which in a read-only file system mode on the container, it fails to analyze images. The work-around I've done for now is to mount an additional volume to /tmp on the container, which is misleading and kind of makes the tmp_dir configuration pointless.
What did you expect to happen:
I expected the scratch directory to be fully used by anchore engine with what I had specified in tmp_dir, shifting anything that was happening under /tmp by anchore to the path specified in tmp_dir configuration like the documentation suggests tmp_dir is for.
What docker images are you using:
registry1.dso.mil/ironbank/anchore/engine/engine:1.0.0
How to reproduce the issue:
An anchore engine setup with --read-only specified when launching the container instance. You will also need to have tmp_dir specified to a mounted volume using a path other than /tmp to reproduce.
Anything else we need to know:
No, think this covers it, but let me know if you need more info.
The text was updated successfully, but these errors were encountered:
It looks like this issue comes from this line in stereoscope which uses os.MkdirTemp. os.MkdirTempuses the value of the TMPDIR env var, so you may be able to set TMPDIR to your writable directory as a workaround.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is this a request for help?:
Not a request for help, it's more a bug or at best reporting misleading documentation.
Is this a BUG REPORT or a FEATURE REQUEST? (choose one):
BUG REPORT
Version of Anchore Engine and Anchore CLI if applicable:
anchore-cli, version 0.9.3
Engine DB Version: 0.0.15
Engine Code Version: 1.0.0
What happened:
I ran anchore as a container with a read-only filesystem as well as a config.yaml that was setup with a tmp_dir specified to a volume I was mounting to the container instance. My tmp_dir path is setup to be /analysis_scratch. When I attempted to analyze an image after adding it via anchore-cli I got an analysis_failed message. Upon investigating and tailing the anchore-worker.log file, I saw error messages where /tmp was still being used by anchore. The tmp_dir directory is being used, but there is still code in anchore that is using /tmp during the unpacking during analysis it looks like, which in a read-only file system mode on the container, it fails to analyze images. The work-around I've done for now is to mount an additional volume to /tmp on the container, which is misleading and kind of makes the tmp_dir configuration pointless.
What did you expect to happen:
I expected the scratch directory to be fully used by anchore engine with what I had specified in tmp_dir, shifting anything that was happening under /tmp by anchore to the path specified in tmp_dir configuration like the documentation suggests tmp_dir is for.
Any relevant log output from /var/log/anchore:
What docker images are you using:
registry1.dso.mil/ironbank/anchore/engine/engine:1.0.0
How to reproduce the issue:
An anchore engine setup with --read-only specified when launching the container instance. You will also need to have tmp_dir specified to a mounted volume using a path other than /tmp to reproduce.
Anything else we need to know:
No, think this covers it, but let me know if you need more info.
The text was updated successfully, but these errors were encountered: