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
- Treat it as non-fatal: the build still proceeds; verify with 'bazel info server_pid'.
- Check free space and write permissions on the output_base/server directory.
- Exclude the output base from antivirus/on-access scanners and sync clients.
- Run 'bazel shutdown' and restart cleanly so the PID file is rewritten.
- If server_pid queries return a stale value, remove server.pid manually while no server is running.
Defensive patterns
Strategy: fallback
Prevention
- Keep the output_base on a local writable volume with free space.
- Do not delete parts of output_base while a server is starting.
- If you script against server.pid, tolerate a missing/stale file (check process liveness).
- Exclude output_base from sync clients that transiently lock server.pid.
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
- Could not seek to end of file (%s)
- Waiting for previous Bazel server's log file to close (waite
- Could not write exit file at ${file}
- Error writing shard file ${shardFile}
- prefix msg "\n"
AI-assisted analysis of bazelbuild/bazel@e6e199d060 (2026-08-14).
Data as JSON: /api/errors/5a0b542bcf4401da.
Report an issue: GitHub.