GoogleContainerTools/jib · warning · IOException

Interrupted while trying to acquire lock

Error message

Interrupted while trying to acquire lock

What it means

Jib's LockFile guards cross-process cache access with a JVM-internal ReentrantLock plus a filesystem FileLock. This IOException is thrown when the thread waiting on the in-JVM ReentrantLock is interrupted before it can acquire it. The thread's interrupt flag is restored before throwing.

Source

Thrown at jib-core/src/main/java/com/google/cloud/tools/jib/filesystem/LockFile.java:61

    this.outputStream = outputStream;
  }

  /**
   * Creates a lock file.
   *
   * @param lockFile the path of the lock file
   * @return a new {@link LockFile} that can be released later
   * @throws IOException if creating the lock file fails
   */
  public static LockFile lock(Path lockFile) throws IOException {
    try {
      // This first lock is to prevent multiple threads from calling FileChannel.lock(), which would
      // otherwise throw OverlappingFileLockException
      lockMap.computeIfAbsent(lockFile, key -> new ReentrantLock()).lockInterruptibly();

    } catch (InterruptedException ex) {
      Thread.currentThread().interrupt();
      throw new IOException("Interrupted while trying to acquire lock", ex);
    }

    Files.createDirectories(lockFile.getParent());
    FileOutputStream outputStream = new FileOutputStream(lockFile.toFile());
    FileLock fileLock = null;
    try {
      fileLock = outputStream.getChannel().lock();
      return new LockFile(lockFile, fileLock, outputStream);

    } finally {
      if (fileLock == null) {
        outputStream.close();
      }
    }
  }

  /** Releases the lock file. */
  @Override

View on GitHub (pinned to fb949e2676)

Solutions

1. Avoid interrupting threads while Jib image build steps are running; check executor shutdown logic
2. Catch the IOException in your build/copy task and handle cancellation gracefully
3. Find and eliminate sources of spurious interruption (e.g. Timer, cancel(true)) around Jib calls
4. Retry the Jib operation after clearing the interruption if cancellation was unintended

Example fix

// before
try {
  jibContainerBuilder.containerize(containerizer);
} catch (IOException e) {
  throw e; // may be lock interruption
}
// after
try {
  jibContainerBuilder.containerize(containerizer);
} catch (IOException e) {
  if (Thread.currentThread().isInterrupted()) {
    Thread.interrupted(); // intentional cancellation, do not retry
    throw e;
  }
  throw new BuildException("Transient lock failure, safe to retry", e);
}

if (Thread.currentThread().isInterrupted()) { throw new CancellationException("Already interrupted; skipping Jib operation"); }

boolean canRunJibOperation(Thread t) { return !t.isInterrupted() && !t.isAlive() == false; } // check interruption before launching

try { jibBuilder.containerize(containerizer); } catch (IOException e) { if (Thread.currentThread().isInterrupted()) { /* intentional cancel: rethrow */ throw new CancellationException(e.getMessage()); } throw e; }

When it happens

Trigger: Calling LockFile.lock() (via Jib cache/registry operations) from a thread that gets interrupted while another thread in the same JVM already holds the ReentrantLock for the same lock file.

Common situations: Task cancellation in build tools (Gradle/Maven daemon shutdown), executor shutdownNow() while Jib builds an image, timeouts implemented via thread interruption.

Related errors

• Unable to release lock

AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06). Data as JSON: /api/errors/b70814e1d1191b38. Report an issue: GitHub.