Waiting for previous Bazel server's log file to close (waite

Error message

Waiting for previous Bazel server's log file to close (waited %d seconds, waiting at most %d)

What it means

On Windows, when the previous Bazel server's jvm.out is still open (sharing violation), the client polls CreateFileW once per second up to timeout_sec and prints this progress notice at 5, 10, and 30 elapsed seconds. It is not a failure by itself: it reports that Bazel is waiting for the dying server to release its log file, and if the timeout expires it gives up and returns INVALID_HANDLE_VALUE.

Source

Thrown at src/main/cpp/blaze_util_windows.cc:599

      if (daemon_out_append &&
          !SetFilePointerEx(handle, {}, nullptr, FILE_END)) {
        fprintf(stderr, "Could not seek to end of file (%s)\n",
                path.AsPrintablePath().c_str());
        return INVALID_HANDLE_VALUE;
      }
      return handle;
    }
    if (GetLastError() != ERROR_SHARING_VIOLATION &&
        GetLastError() != ERROR_LOCK_VIOLATION) {
      // Some other error occurred than the file being open; bail out.
      break;
    }

    // The file is still held open, the server is shutting down. There's a
    // chance that another process holds it open, we don't know; in that case
    // we just exit after the timeout expires.
    if (waited == 5 || waited == 10 || waited == 30) {
      fprintf(stderr,
              "Waiting for previous Bazel server's log file to close "
              "(waited %d seconds, waiting at most %d)\n",
              waited, timeout_sec);
    }
    Sleep(1000);
  }
  return INVALID_HANDLE_VALUE;
}

class ProcessHandleBlazeServerStartup : public BlazeServerStartup {
 public:
  ProcessHandleBlazeServerStartup(HANDLE _proc) : proc(_proc) {}

  bool IsStillAlive() override {
    FILETIME dummy1, exit_time, dummy2, dummy3;
    return GetProcessTimes(proc, &dummy1, &exit_time, &dummy2, &dummy3) &&
           exit_time.dwHighDateTime == 0 && exit_time.dwLowDateTime == 0;
  }

View on GitHub (pinned to e6e199d060)

Solutions

Simply wait: the message is informational and the wait usually succeeds once the old server exits.
If waits keep timing out, run 'bazel shutdown', then confirm no java process holds jvm.out (Resource Monitor / handle.exe) before rerunning.
For scripted restarts, add a few seconds of delay or poll 'bazel info' instead of hammering the same output_base.
Give each concurrent job its own --output_base to avoid two clients contending for one server log.

Example fix

# before (CI): bazel kill %BAZEL_SERVER% ; bazel build //pkg
# after: bazel shutdown && sleep 10 && bazel build //pkg
# or isolate: bazel --output_base=C:/_ci/%BUILD_ID% build //pkg

Defensive patterns

Strategy: retry

Prevention

Treat the message as progress, not failure; do not kill Bazel while it waits.
Insert a small delay between 'bazel shutdown' and the next build in scripts.
Use one output_base per concurrent client to avoid log-file contention.
If waits exceed 30s regularly, investigate why the JVM server is slow to exit (heap dumps, antivirus).

When it happens

Trigger: Immediately rerunning a Bazel command after interrupting the previous one while the JVM server is still flushing and exiting; two clients racing on the same output_base; the server hung in shutdown holding the log handle longer than the wait timeout.

Common situations: CI scripts that kill bazel and restart at once; interactive Ctrl-C followed by a quick rerun; overloaded Windows machines where the JVM takes tens of seconds to exit.

Related errors

AI-assisted analysis of bazelbuild/bazel@e6e199d060 (2026-08-14). Data as JSON: /api/errors/149f23d8b6e9a743. Report an issue: GitHub.