Skip to content
Latchkey

Bamboo build failing on database lock / connection in CI

A build task that talks to a database failed because the database was locked by a concurrent process, or the connection was refused. This is a build-time data problem, distinct from the Bamboo server's own database.

What this error means

The build fails with "database is locked", "could not obtain lock", or "Connection refused" from the test or migration step that uses a database.

Bamboo
org.sqlite.SQLiteException: [SQLITE_BUSY] The database file is locked (database is locked)
Failing task since return code of the command was 1 and not 0.

Common causes

Concurrent builds share one database

Multiple builds on the same agent use a single shared database file or instance, so one holds a lock the other cannot obtain.

The database service is not up when the build runs

The test database container or service was not started or not ready, so the build's connection is refused.

How to fix it

Isolate the database per build

  1. Give each build its own database instance or file so concurrent runs do not contend.
  2. For containerized DBs, start a fresh service container per build and tear it down after.
  3. Re-run so the build has an uncontended database.
Script task
# start an isolated Postgres per build (example)
docker run -d --name db-$bamboo_buildNumber -e POSTGRES_PASSWORD=ci -p 0:5432 postgres:16

Wait for the database to be ready

Add a readiness check before the DB-using task so the build does not run against a not-yet-started database.

Terminal
until pg_isready -h 127.0.0.1 -p 5432; do sleep 1; done

How to prevent it

  • Use an isolated database per build to avoid lock contention.
  • Add readiness checks before tasks that connect to a database.
  • Limit concurrent builds sharing any single database resource.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →