Sometimes, update failed. Got timeout

[ciltocruz]

Drydock version

1.5.1-rc.5

What happened?

Sometimes I get a Trivy timeout error when updating.

See logs section.

Then, on a second attempt, it seems to work. It's as if the image takes a long time to download, causing the process to fail. On the second attempt, once the image is downloaded, it seems to work better.

What did you expect?

Updated successfully.

Steps to reproduce

1. Trying to update an image, perhaps a very large one (I don't know).
2. Waiting for the timeout error to occur. It seems random.

Relevant configuration

Logs

`Container kometa update failed: Security scan failed: Trivy command failed (exit=unknown): Command failed: trivy image --quiet --format json --timeout 120s --scanners vuln --severity UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL kometateam/kometa:latest`

Installation method

Docker Compose

Docker version

No response

OS / Architecture

No response

[scttbnsn]

Dug into this one properly. It's real, it's been there since the scanner shipped in v1.3.0 (nothing the rc line changed), and your read is basically right: the scan runs right after the image is pulled, and big images make it blow the budget.

Three things stack up against you on the first attempt:

1. The scan has a 120s default budget, and the first scan after a drydock restart also pays Trivy's vulnerability-DB download inside that same window.
2. The timeout that actually fires is our process-level one, which kills Trivy mid-run. That's why the error says exit=unknown instead of something useful.
3. On a failed scan we currently prune the image that was just pulled, so your second attempt re-downloads everything (it works then because Trivy's DB is cached by that point).

Workaround today: raise the scan budget with DD_SECURITY_TRIVY_TIMEOUT (milliseconds, e.g. DD_SECURITY_TRIVY_TIMEOUT=600000 for 10 min). If you run a lot of large images, DD_SECURITY_TRIVY_SERVER pointed at a trivy server instance also takes the DB download out of the per-scan cost entirely — both are in the security docs.

The proper fix package is queued for v1.6: default timeout bumped to 600s, honest timeout errors instead of exit=unknown, one automatic retry on transient scan errors, no more pruning the pulled image when the scan errors (vs actually finding blockers), and the DB download decoupled from the scan budget. Leaving this open until that ships. Thanks for another solid report.

[ciltocruz]

Thanks for another solid report.

Thank you. I really like this project. I try to help out as much as I can.
In fact, I've spent the weekend adding quite a few translations from my language 😂😂😂

[scttbnsn]

Thanks dude, glad you like it and excited the translations are actually being used!

Also yes than you for anything you raise, it helps a ton.