anchore
No space left error
What happened: Can't use the tool to scan due to an error that no space left on the device, even though i have enough space
└─$ grype db update -vvv
[0000] INFO grype version: 0.84.0
[0000] DEBUG config:
log:
quiet: false
level: trace
file: ""
dev:
profile: none
db:
cache-dir: /home/groot/.cache/grype/db
update-url: https://toolbox-data.anchore.io/grype/databases/listing.json
ca-cert: ""
auto-update: true
validate-by-hash-on-start: false
validate-age: true
max-allowed-built-age: 120h0m0s
require-update-check: true
update-available-timeout: 30s
update-download-timeout: 5m0s
max-update-check-frequency: 2h0m0s
[0000] TRACE no max-frequency set for update check
[0000] DEBUG checking for available database updates
[0000] DEBUG found database update candidate: Listing(url=https://grype.anchore.io/databases/vulnerability-db_v5_2024-11-19T01:31:45Z_1731990207.tar.gz)
[0000] DEBUG cannot find existing metadata, using update...
[0000] DEBUG database update available: Listing(url=https://grype.anchore.io/databases/vulnerability-db_v5_2024-11-19T01:31:45Z_1731990207.tar.gz)
[0000] INFO downloading new vulnerability DB
[0004] TRACE worker stopped component=eventloop
[0004] TRACE signal exit component=eventloop
unable to update vulnerability database: unable to update vulnerability database: unable to download db: write /tmp/getter2468548383/archive: no space left on device
What you expected to happen:
Get no error when scanning,
How to reproduce it (as minimally and precisely as possible):
grype
Environment:
-
Output of
grype version: Application: grype Version: 0.84.0 BuildDate: 2024-11-05T14:54:52Z GitCommit: c8d5ffca8d304e0fd5db04fce109fe0d91fa5781 GitDescription: v0.84.0 Platform: linux/amd64 GoVersion: go1.23.2 Compiler: gc Syft Version: v1.16.0 Supported DB Schema: 5 -
OS (e.g:
cat /etc/os-releaseor similar): PRETTY_NAME="Kali GNU/Linux Rolling" NAME="Kali GNU/Linux" VERSION_ID="2024.3" VERSION="2024.3" VERSION_CODENAME=kali-rolling ID=kali ID_LIKE=debian HOME_URL="https://www.kali.org/" SUPPORT_URL="https://forums.kali.org/" BUG_REPORT_URL="https://bugs.kali.org/" ANSI_COLOR="1;31"
@rootlikegroot do you have any details on the volumes on the system?
Is there maybe a /tmp or home volume that is out of space that grype is operating on?
Grype downloads the DB to TMPDIR and then copies the contents over to home. Maybe one of these locations is running out of space before grype can execute?
Further to @spiffcs comment - you can override TMPDIR to point to somewhere that you do have space.
alan@Alans-MacBook-Pro ~ mkdir $HOME/tmp
alan@Alans-MacBook-Pro ~ export TMPDIR=$HOME/tmp
alan@Alans-MacBook-Pro ~ echo $TMPDIR
/Users/alan/tmp
alan@Alans-MacBook-Pro ~ grype db update
⠴ Vulnerability DB ━━━━━━━━━━━━━━━━━━━━ [118 MB / 199 MB]
CTRL+C
alan@Alans-MacBook-Pro ~ ls $HOME/tmp
getter2404191555 grype-scratch2315966201
Could you please this configuration setting available on the grype config file, so I don't have to set this env var all the time? Thanks!
Hey @aborrero, it looks like this is for the grype database download, is that right? Are you able to use the GRYPE_DB_CACHE_DIR? In the config file it's:
db:
# location to write the vulnerability database cache (env: GRYPE_DB_CACHE_DIR)
cache-dir: '<dir>'
... there was a recently fixed issue where the db was being downloaded to a temporary file outside of that dir, but it now should be downloaded to a temporary file in that dir. Maybe I'm missing a detail here... is the problem that go-getter is downloading the archive to /tmp and then decompressing it to the db cache dir, and then moving it? If this is the case, we really need to figure out how to make go-getter honor the configured cache dir as a temporary download location. I couldn't quite figure it out with a brief look, but perhaps we need to do an os.SetEnv("TEMP",...) or similar...
(Is this for the listing file? That should use the same cache dir as a root for the temporary file, but it doesn't appear to be doing that today)
no, I believe the space issue is with unpacking the image, not with the vuln database.
@aborrero the original report was for grype db update, which does not perform a scan. Adding configuration for the temporary image location will need to be plumbed in to stereoscope, but I agree is a good addition 👍 It looks like there is an issue for this today: https://github.com/anchore/stereoscope/issues/287 after this gets implemented, we will need to plumb options through in Syft and Grype.