bazelbuild/bazel · warning

Cannot write PID file %s

Error message

Cannot write PID file %s

What it means

After the Bazel client spawns the server process on Windows, it writes the new server's PID to output_base/server/server.pid via blaze_util::WriteFile; if that write fails it only prints this warning and continues (the code comment notes 'Not a lot we can do'). Consequences are limited: tooling that reads the pid file (e.g. shutdown heuristics) may see a stale PID until the next successful write.

Source

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

  }

  if (!ok) {
    string err = GetLastErrorString();
    BAZEL_DIE(blaze_exit_code::LOCAL_ENVIRONMENTAL_ERROR)
        << "ExecuteDaemon(" << exe.AsPrintablePath() << "): CreateProcess("
        << cmdline.cmdline << ") failed: " << err;
  }

  WriteProcessStartupTime(server_dir, processInfo.hProcess);

  // Pass ownership of processInfo.hProcess
  *server_startup = new ProcessHandleBlazeServerStartup(processInfo.hProcess);

  string pid_string = blaze_util::ToString(processInfo.dwProcessId);
  blaze_util::Path pid_file = server_dir.GetRelative(kServerPidFile);
  if (!blaze_util::WriteFile(pid_string, pid_file)) {
    // Not a lot we can do if this fails
    fprintf(stderr, "Cannot write PID file %s\n",
            pid_file.AsPrintablePath().c_str());
  }

  // Don't close processInfo.hProcess here, it's now owned by the
  // ProcessHandleBlazeServerStartup instance.
  CloseHandle(processInfo.hThread);

  return processInfo.dwProcessId;
}

// Run the given program in the current working directory, using the given
// argument vector, wait for it to finish, then exit ourselves with the exitcode
// of that program.
ATTRIBUTE_NORETURN static void ExecuteProgram(
    const blaze_util::Path& exe,
    const std::vector<std::wstring>& wargs_vector) {
  CmdLine cmdline;
  CreateCommandLine(&cmdline, blaze_util::Path(), wargs_vector);

View on GitHub (pinned to e6e199d060)

Solutions

  1. Treat it as non-fatal: the build still proceeds; verify with 'bazel info server_pid'.
  2. Check free space and write permissions on the output_base/server directory.
  3. Exclude the output base from antivirus/on-access scanners and sync clients.
  4. Run 'bazel shutdown' and restart cleanly so the PID file is rewritten.
  5. If server_pid queries return a stale value, remove server.pid manually while no server is running.
Defensive patterns

Strategy: fallback

Prevention

When it happens

Trigger: server.pid or its directory is read-only or was deleted concurrently; the output base is on a full or quota-exceeded volume; antivirus/sync software transiently locks server.pid right after server start.

Common situations: Output base on a synced/network drive with delayed lock release; disk-full CI agents; users manually deleting parts of output_base while a server is starting.

Related errors


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