Skip to content
Latchkey

Gradle "Timeout waiting to lock" file cache in CI

Gradle uses file locks on its caches under ~/.gradle. When another Gradle process holds the lock (or a stale lock was left behind), a second process waits and then fails with "Timeout waiting to lock".

What this error means

The build fails with "Timeout waiting to lock ... Owner PID: ... Our PID: ..." naming a file under .gradle or ~/.gradle/caches, often when jobs share a cache directory.

Gradle
> Timeout waiting to lock journal cache (/home/runner/.gradle/caches/journal-1).
  It is currently in use by another Gradle instance.
  Owner PID: 12345
  Our PID: 12377
  Owner Operation:
  Our operation:

Common causes

Two Gradle builds share one cache directory

Parallel jobs or matrix legs running against the same mounted ~/.gradle contend for the same lock, and one times out.

A stale lock from a killed process

A previous Gradle process was killed (OOM, cancelled job) and left a lock file that a later build waits on.

How to fix it

Give each job an isolated Gradle home

  1. Avoid sharing one writable ~/.gradle across concurrent jobs.
  2. Point GRADLE_USER_HOME at a per-job directory, or serialise the jobs.
  3. Restore a read-cache separately from the writable working home.
.github/workflows/ci.yml
env:
  GRADLE_USER_HOME: ${{ runner.temp }}/gradle-home

Clear a stale lock and retry

If no other Gradle is running, the lock is stale. Remove the orphaned lock file (or the offending cache subdirectory) and re-run.

Terminal
rm -f ~/.gradle/caches/journal-1/*.lock
./gradlew build --no-daemon

How to prevent it

  • Do not share one writable ~/.gradle across concurrent jobs.
  • Set a distinct GRADLE_USER_HOME per job when running in parallel.
  • Use --no-daemon so daemons do not linger and hold locks.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →