Running Trivy 0.66 in parallel crashes as the databaset might be used by another Trivy

[kaiorafael]

Description

Running multiple instances from Trivy generates error as the database might be used by other Trivy. This behavior was not there on 0.63.

2025-09-24T21:16:01Z    DEBUG   Default config file "file_path=trivy.yaml" not found, using built in values
2025-09-24T21:16:01Z    DEBUG   Cache dir       dir="/root/.cache/trivy"
2025-09-24T21:16:01Z    DEBUG   Cache dir       dir="/root/.cache/trivy"
2025-09-24T21:16:01Z    DEBUG   Parsed severities       severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2025-09-24T21:16:01Z    DEBUG   Ignore statuses statuses=[0 1 2 4 5 6 7]
2025-09-24T21:16:01Z    DEBUG   [vulndb] Skipping DB update...
2025-09-24T21:16:01Z    DEBUG   DB info schema=2 updated_at=2025-09-24T06:25:26.717251712Z next_update=2025-09-25T06:25:26.717251552Z downloaded_at=2025-09-24T11:07:37.272481397Z
2025-09-24T21:16:06Z    FATAL   Fatal error
  - run error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.Run
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:414
  - init error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.run
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:431
  - DB error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.NewRunner
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:136
  - error in vulnerability DB initialize:
    github.com/aquasecurity/trivy/pkg/commands/artifact.(*runner).initDB
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:333
  - Oops: vulnerability database may be in use by another process: timeout
    Time: 2025-09-24 21:16:01.46195849 +0000 UTC
    Trace: 01K5YSARX09F8M1HF586796W5W
    Context:
      * db_dir: /root/.cache/trivy/db
      * database: bbolt
      * db_path: /root/.cache/trivy/db/trivy.db
    Stacktrace:
      Oops: vulnerability database may be in use by another process
        --- at /home/runner/go/pkg/mod/github.com/aquasecurity/[email protected]/pkg/db/db.go:118 Init()
        --- at /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:332 runner.initDB()
        --- at /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:135 NewRunner()
        --- at /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:426 run()
        --- at /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:412 Run()
        --- at /home/runner/work/trivy/trivy/pkg/commands/app.go:317 NewImageCommand.func2()
        --- at /home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1015 Command.execute()
        --- at /home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1148 Command.ExecuteC()
        --- at /home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1071 Command.Execute()
        --- at /home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1064 Command.ExecuteContext()

Desired Behavior

I need to run multiple instances of Trivy to scan a set of local container images. On version 0.63 that methodology was valid, but by updating to the newest version this is not possible anymore.

Actual Behavior

Error

    Stacktrace:
      Oops: vulnerability database may be in use by another process
        --- at /home/runner/go/pkg/mod/github.com/aquasecurity/[email protected]/pkg/db/db.go:118 Init()

Reproduction Steps

Run in parallel Trivy 0.66 as Docker image to scan other Docker images in the same host:
example:


docker run -v /var/run/docker.sock:/var/run/docker.sock -v /tmp:/tmp -v /home/ec2-user/.cache:/root/.cache/ xxxx.dkr.ecr.xxxx.amazonaws.com/trivy image --no-progress --ignore-unfixed --skip-db-update --skip-java-db-update --offline-scan --skip-check-update --pkg-types os --scanners vuln --timeout 10m -f json --output /tmp/alpine.json xxxx.dkr.ecr.xxxx.amazonaws.com/alpine

I have a Python that runs in parallel Trivy as above for 13 different local repo. They are not executed as sequential.

### Target

Container Image

### Scanner

Vulnerability

### Output Format

JSON

### Mode

Standalone

### Debug Output

If I run for each project individually it works as expected. 

```bash

2025-09-24T23:26:26Z    DEBUG   No plugins loaded
2025-09-24T23:26:26Z    DEBUG   Default config file "file_path=trivy.yaml" not found, using built in values
2025-09-24T23:26:26Z    DEBUG   Cache dir       dir="/root/.cache/trivy"
2025-09-24T23:26:26Z    DEBUG   Cache dir       dir="/root/.cache/trivy"
2025-09-24T23:26:26Z    DEBUG   Parsed severities       severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2025-09-24T23:26:26Z    DEBUG   Ignore statuses statuses=[0 1 2 4 5 6 7]
2025-09-24T23:26:26Z    DEBUG   [vulndb] Skipping DB update...
2025-09-24T23:26:26Z    DEBUG   DB info schema=2 updated_at=2025-09-24T06:25:26.717251712Z next_update=2025-09-25T06:25:26.717251552Z downloaded_at=2025-09-24T11:07:37.272481397Z
2025-09-24T23:26:26Z    DEBUG   [pkg] Package types     types=[os]
2025-09-24T23:26:26Z    DEBUG   [pkg] Package relationships     relationships=[unknown root workspace direct indirect]
2025-09-24T23:26:26Z    INFO    [vuln] Vulnerability scanning is enabled
2025-09-24T23:26:26Z    DEBUG   Initializing scan cache...      type="fs"
2025-09-24T23:26:26Z    DEBUG   [notification] Running version check
2025-09-24T23:26:26Z    DEBUG   Created process-specific temp directory path="/tmp/trivy-1"
2025-09-24T23:26:26Z    DEBUG   [image] Image found     image="xxxxxx/alpine" source="docker"
2025-09-24T23:26:26Z    DEBUG   [image] Detected image ID       image_id="sha256:4048db5d......19713483a68641fce"
2025-09-24T23:26:26Z    DEBUG   [image] Detected diff ID        diff_ids=[sha256:3e01818d79c.......82344b8c24e7]
2025-09-24T23:26:26Z    DEBUG   [image] Detected base layers    diff_ids=[]
2025-09-24T23:26:26Z    INFO    Detected OS     family="alpine" version="3.21.0"
2025-09-24T23:26:26Z    INFO    [alpine] Detecting vulnerabilities...   os_version="3.21" repository="3.21" pkg_num=15
2025-09-24T23:26:26Z    WARN    Using severities from other vendors for some vulnerabilities. Read https://trivy.dev/v0.66/docs/scanner/vulnerability#severity-selection for details.
2025-09-24T23:26:26Z    DEBUG   Specified ignore file does not exist    file=".trivyignore"
2025-09-24T23:26:26Z    DEBUG   [vex] VEX filtering is disabled
2025-09-24T23:26:26Z    DEBUG   Cleaning up temp directory      path="/tmp/trivy-1"

Operating System

Linux

Version

$ docker run -v /var/run/docker.sock:/var/run/docker.sock -v /tmp:/tmp -v /home/ec2-user/.cache:/root/.cache/ xxx.dkr.ecr.xxx.amazonaws.com/trivy --version
Version: 0.66.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2025-09-24 06:25:26.717251712 +0000 UTC
  NextUpdate: 2025-09-25 06:25:26.717251552 +0000 UTC
  DownloadedAt: 2025-09-24 11:07:37.272481397 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2025-09-19 00:54:37.956239064 +0000 UTC
  NextUpdate: 2025-09-22 00:54:37.956238904 +0000 UTC
  DownloadedAt: 2025-09-19 11:07:26.461551133 +0000 UTC

Checklist

• Run trivy clean --all
• Read the troubleshooting

[knqyf263]

https://trivy.dev/latest/docs/references/troubleshooting/#database-and-cache-lock-errors

[kaiorafael]

Thanks for posting the response. I think that explain the behavior, I have seen that document before. However, the change in 0.66 breaks how Trivy has been working for while. I am 100% that changes have been made to improve how Trivy works, but by providing argument like --skip-db-update --skip-java-db-update --offline-scan --skip-check-update no DB is read-write action is performed IMHO.

It would be great if Trivy could keep same behavior as .063, 0.64. In version 0.65 there the docs says that running Trivy in parallel or sequential were about the same time, but with 0.66 the process simple breaks :)

Thank you.

[knqyf263]

The document explains that the completion time is the same whether Trivy is executed sequentially or in parallel, so there is no point in running it in parallel. In other words, previously, it only looked like it was working incorrectly when, in fact, it had no meaning (one process was just waiting for the other), which could be considered a bug. This has now been properly fixed.

Also, even if you specify options such as --skip-db-update, the cache will be locked. If you need a cache backend that does not lock, please refer to this document.
https://trivy.dev/latest/docs/configuration/cache/#scan-cache-backend