Parallel scans utilizing same cache dir failing with 0.66.0

[bluesliverx]

Description

We've been using trivy for about a year and a half in a Jenkins build grid that handled hundreds of parallel builds each day. Not all of these are scanned (since not all create Docker images), but many do. Starting in the last week, we started getting this error when running many parallel builds at the same time:

00:11:35  2025-09-11 23:11:35,077 INFO     + trivy --version
00:11:35  2025-09-11 23:11:35,144 INFO     Version: 0.66.0
00:11:35  2025-09-11 23:11:35,144 INFO     Vulnerability DB:
00:11:35  2025-09-11 23:11:35,144 INFO       Version: 2
00:11:35  2025-09-11 23:11:35,145 INFO       UpdatedAt: 2025-09-11 12:34:02.614406733 +0000 UTC
00:11:35  2025-09-11 23:11:35,145 INFO       NextUpdate: 2025-09-12 12:34:02.614406482 +0000 UTC
00:11:35  2025-09-11 23:11:35,145 INFO       DownloadedAt: 2025-09-11 18:59:22.063442126 +0000 UTC
00:11:35  2025-09-11 23:11:35,145 INFO     Java DB:
00:11:35  2025-09-11 23:11:35,145 INFO       Version: 1
00:11:35  2025-09-11 23:11:35,145 INFO       UpdatedAt: 2025-09-10 00:53:52.013768699 +0000 UTC
00:11:35  2025-09-11 23:11:35,146 INFO       NextUpdate: 2025-09-13 00:53:52.013768519 +0000 UTC
00:11:35  2025-09-11 23:11:35,146 INFO       DownloadedAt: 2025-09-10 20:39:12.983477263 +0000 UTC
00:11:35  2025-09-11 23:11:35,200 INFO     + trivy --config /trivy/config.yaml image -f json -o /trivy/results.json <my-docker-image>
00:11:35  2025-09-11 23:11:35,262 INFO     2025-09-12T06:11:35Z INFO  Loaded  file_path="/trivy/config.yaml"
00:11:40  2025-09-11 23:11:40,252 INFO     2025-09-12T06:11:40Z FATAL Fatal error run error: init error: DB error: error in vulnerability DB initialize: vulnerability database may be in use by another process: timeout

Our trivy config looks like this (or at least, it's generated from this yaml):

cache-dir: /mnt/caches/trivy
timeout: '20m'
'exit-code': 0
db:
  repository: '<ghcr.io-mirror>/aquasecurity/trivy-db:2'
severity:
- 'HIGH'
- 'CRITICAL'

Also note that we use an internal mirror for the ghcr.io registry so we're not hitting rate limits or anything there. Our cache directory is on an NFS mount, which we have been using without issues since last February.

We use the latest docker image for trivy (aquasec/trivy:latest), and this problem seems to coincide with the 0.66.0 release this last week. We downgraded to 0.65.0, and the issues went away again, so it seems clearly related to something done in the new version.

Trying the jobs one at a time fixes things, but that does not work for us, so we've downgraded to 0.65.0 until this issue can be addressed.

Please note I've read through the troubleshooting and see that this may not be recommended. However, before the process waits for some amount of time for the lockfiles to be released and that's worked fine for us. We even have a timeout set at 20m. However, this fails immediately without waiting at all for the lock file to be cleaned up. This feels like the real problem here - it doesn't wait where it used to.

Desired Behavior

The trivy image scan works

Actual Behavior

Fatal error run error: init error: DB error: error in vulnerability DB initialize: vulnerability database may be in use by another process: timeout

Reproduction Steps

1. Use the config above with a common cache dir
2. Run many trivy scans at the same time (we reproduced it with ~10 builds running at the same time)
3. See error

Target

Container Image

Scanner

Vulnerability

Output Format

JSON

Mode

Standalone

Debug Output

16:55:17  2025-09-12 15:55:17,600 INFO     + trivy --config /trivy/config.yaml image -f json -o /trivy/results.json <my-docker-image>
16:55:17  2025-09-12 15:55:17,662 INFO     2025-09-12T22:55:17Z DEBUG No plugins loaded
16:55:17  2025-09-12 15:55:17,662 INFO     2025-09-12T22:55:17Z INFO  Loaded  file_path="/trivy/config.yaml"
16:55:17  2025-09-12 15:55:17,662 INFO     2025-09-12T22:55:17Z DEBUG Cache dir dir="/root/.cache/trivy"
16:55:17  2025-09-12 15:55:17,663 INFO     2025-09-12T22:55:17Z DEBUG Cache dir dir="/root/.cache/trivy"
16:55:17  2025-09-12 15:55:17,665 INFO     2025-09-12T22:55:17Z DEBUG Parsed severities severities=[HIGH CRITICAL]
16:55:17  2025-09-12 15:55:17,666 INFO     2025-09-12T22:55:17Z DEBUG Ignore statuses statuses=[]
16:55:17  2025-09-12 15:55:17,667 INFO     2025-09-12T22:55:17Z DEBUG DB update was skipped because the local DB is the latest
16:55:17  2025-09-12 15:55:17,667 INFO     2025-09-12T22:55:17Z DEBUG DB info schema=2 updated_at=2025-09-12T12:27:53.268361866Z next_update=2025-09-13T12:27:53.268361646Z downloaded_at=2025-09-12T20:25:27.033191788Z
16:55:22  2025-09-12 15:55:22,654 INFO     2025-09-12T22:55:22Z FATAL Fatal error
16:55:22  2025-09-12 15:55:22,654 INFO       - run error:
16:55:22  2025-09-12 15:55:22,654 INFO         github.com/aquasecurity/trivy/pkg/commands/artifact.Run
16:55:22  2025-09-12 15:55:22,654 INFO             /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:414
16:55:22  2025-09-12 15:55:22,654 INFO       - init error:
16:55:22  2025-09-12 15:55:22,655 INFO         github.com/aquasecurity/trivy/pkg/commands/artifact.run
16:55:22  2025-09-12 15:55:22,655 INFO             /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:431
16:55:22  2025-09-12 15:55:22,655 INFO       - DB error:
16:55:22  2025-09-12 15:55:22,655 INFO         github.com/aquasecurity/trivy/pkg/commands/artifact.NewRunner
16:55:22  2025-09-12 15:55:22,655 INFO             /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:136
16:55:22  2025-09-12 15:55:22,655 INFO       - error in vulnerability DB initialize:
16:55:22  2025-09-12 15:55:22,656 INFO         github.com/aquasecurity/trivy/pkg/commands/artifact.(*runner).initDB
16:55:22  2025-09-12 15:55:22,656 INFO             /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:333
16:55:22  2025-09-12 15:55:22,656 INFO       - Oops: vulnerability database may be in use by another process: timeout
16:55:22  2025-09-12 15:55:22,656 INFO         Time: 2025-09-12 22:55:17.667361977 +0000 UTC
16:55:22  2025-09-12 15:55:22,656 INFO         Trace: 01K5027XGXGKD5PA276S48V465
16:55:22  2025-09-12 15:55:22,656 INFO         Context:
16:55:22  2025-09-12 15:55:22,657 INFO           * db_path: /root/.cache/trivy/db/trivy.db
16:55:22  2025-09-12 15:55:22,657 INFO           * db_dir: /root/.cache/trivy/db
16:55:22  2025-09-12 15:55:22,657 INFO           * database: bbolt
16:55:22  2025-09-12 15:55:22,657 INFO         Stacktrace:
16:55:22  2025-09-12 15:55:22,657 INFO           Oops: vulnerability database may be in use by another process
16:55:22  2025-09-12 15:55:22,658 INFO             --- at /home/runner/go/pkg/mod/github.com/aquasecurity/[email protected]/pkg/db/db.go:118 Init()
16:55:22  2025-09-12 15:55:22,658 INFO             --- at /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:332 runner.initDB()
16:55:22  2025-09-12 15:55:22,658 INFO             --- at /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:135 NewRunner()
16:55:22  2025-09-12 15:55:22,658 INFO             --- at /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:426 run()
16:55:22  2025-09-12 15:55:22,658 INFO             --- at /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:412 Run()
16:55:22  2025-09-12 15:55:22,658 INFO             --- at /home/runner/work/trivy/trivy/pkg/commands/app.go:317 NewImageCommand.func2()
16:55:22  2025-09-12 15:55:22,659 INFO             --- at /home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1015 Command.execute()
16:55:22  2025-09-12 15:55:22,659 INFO             --- at /home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1148 Command.ExecuteC()
16:55:22  2025-09-12 15:55:22,659 INFO             --- at /home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1071 Command.Execute()
16:55:22  2025-09-12 15:55:22,659 INFO             --- at /home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1064 Command.ExecuteContext()

Operating System

Rocky Linux release 8.7 (Green Obsidian)

Version

0.66.0 (included in output above)

Checklist

• Run trivy clean --all
• Read the troubleshooting

[knqyf263]

Trivy's standalone mode was not designed to run in parallel, and in the past, it caused confusing errors because it did not explicitly return an error. Since v0.66.0, it explicitly returns an error to prevent users from making such mistakes. For more details, please refer to the following.
https://trivy.dev/v0.66/docs/references/troubleshooting/#database-and-cache-lock-errors