Bazel Knowledge Hub

1.1.4 Inspecting Server State

extra

Some Bazel server state survives on disk, while some exists only in the running process. Knowing which kind you are looking for makes troubleshooting much less mysterious: you can inspect files under output_base, but a server restart discards its in-memory analysis state. 1.1.3 Server/Client Architecture explains why Bazel uses the long-lived server in the first place.1,2,3

Which Bazel server state survives a restart?
The running server uses files on disk and a dependency graph in memory
RUNNING BAZEL SERVER
One process owns both layers
ON DISK
What remains on disk?
Stored under output_base
server/
action_cache/
execroot/
CLI INSPECTION
bazel info output_base
IN MEMORY
What is lost on restart?
Skyframe graph in server memory
loaded BUILD files
dependency graph
analysis metadata
INSPECT THE IN-MEMORY GRAPH
bazel dump --skyframe=summary
Files under output_base remain after the server stops. The in-memory Skyframe graph does not.

What Lives Under output_base

Bazel state is split across several surfaces. Under $(bazel info output_base) you can inspect durable directories such as server/, action_cache/, and execroot/.4,5 If 0.1.4 Output Root explained where Bazel stores outputs, this is the server-facing half of the same tree.

$(bazel info output_base)/
├── action_cache/   # persistent metadata on disk
├── server/         # logs, socket, server files
└── execroot/       # working tree for actions (bazel-out/ lives here)

The bazel-out/ symlink you see in the workspace root points into execroot/ under this tree. server/ holds server-side files such as logs and sockets, action_cache/ is persistent metadata on disk, and execroot/ is the working tree for actions.4

The In-Memory Analysis Cache

The analysis cache lives inside the running server process rather than in another directory under output_base. It keeps loaded BUILD files, dependency-graph analysis, and related incremental state.1,2,3 The loading phase caches parsed BUILD files. The analysis phase caches the dependency graph for the requested targets, so later commands can often skip most of that work when nothing relevant changed.3

What you can inspect from the CLI

You do not need a deep debugger to answer the first useful questions:

bazel info output_base
bazel info server_pid
bazel info server_log
bazel dump --skyframe=summary

bazel info output_base answers "where is the on-disk state?"5 server_pid and server_log answer "which process is serving me, and where is its log?"5 bazel dump --skyframe=summary goes one step further: it exposes a developer-facing dump of the dependency graph held in the server's analysis cache.5 dump is intended primarily for Bazel developers, and its output is not specified and may change.5

What You Need To Know For Troubleshooting

You do not need SkyKey, SkyValue, or the evaluator protocol to troubleshoot ordinary server state. First decide whether you are looking for a file under output_base or for in-memory state that vanished with the server.2,5

Later levels give names to the pieces of that cache. 2.4.1 Skyframe & Incrementality explains why Bazel can invalidate only the affected parts of the dependency graph, and 5.9 Skyframe explains the internal data model behind that behavior.

key takeaway

The Bazel server exposes two observable layers: inspectable directories under output_base, and warm analysis state inside the running server process. Use bazel info, server_pid, and server_log for the disk-backed layer. Treat bazel dump --skyframe=summary as a narrow, unstable preview. 2.4.1 Skyframe & Incrementality explains the mechanism behind the in-memory graph.

Check your understanding · 2 questions

1.Match each server-state surface to where it lives:

Drag each answer onto the matching prompt, or click an answer and then click a prompt

Answers
action_cache/
server/
analysis cache

2.Which command is the stable operator-facing way to locate the active server log?

Select one answer

0 of 2 answered

Footnotes

  1. Client/server implementation — long-lived server, cached metadata across invocations, and the client/server split ↩1 ↩2

  2. Optimize Iteration Speed — analysis cache lives in server memory and is lost when the server exits ↩1 ↩2 ↩3

  3. Build programs with Bazel — loading caches BUILD files and analysis caches the dependency graph across builds ↩1 ↩2 ↩3

  4. Output Directory Layout — outputBase contents including server/, action_cache/, and execroot/ ↩1 ↩2

  5. Commands and Options — bazel info output_base, server_pid, server_log, and dump --skyframe. dump output is intended for Bazel developers and may change ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

← PreviousServer/Client ArchitectureNext →--keep_going (-k)