skip to content

How do you inspect which Gradle daemons are running and how do you stop them from the command line?

level: juniorimportance: must knowfreq 70%

answer

  1. --status lists PID/STATUS/version
  2. same-version only
  3. --stop = graceful, all compatible
  4. no single-daemon targeting
  5. registry.bin under GRADLE_USER_HOME/daemon

basics

~10 s

Run gradle --status to list daemons and their state, and gradle --stop to gracefully stop all idle and compatible daemons started by the current Gradle version.

solid answer

~30 s

`gradle --status` prints the daemons Gradle knows about: their PID, the Gradle version, their status (IDLE, BUSY) and uptime. It only lists daemons for the **same Gradle version** as the one you invoke, and skips daemons in unrecognised states. `gradle --stop` sends a graceful stop request to all daemons that the current version can talk to — they finish nothing in flight (idle ones exit, you cannot selectively stop one). Both commands read the daemon **registry** under `GRADLE_USER_HOME/daemon/<version>/registry.bin`. For a hard kill you fall back to the OS (`kill <pid>`), because `--stop` won't touch incompatible-version or stuck daemons.

code

bash · 8 lines
bash
# inspect daemons known to THIS gradle version
gradle --status

# stop all compatible daemons (graceful)
gradle --stop

# hard-kill a stuck or wrong-version daemon
kill <pid>   # PID from --status / OS tooling

go deeper

for a junior

Know the two commands and what they do: --status lists, --stop stops all.

for a middle

Add the same-version-only caveat and that --stop is graceful and all-or-nothing.

for a senior

Explain the registry backing both commands and when to fall back to an OS kill.

for a principal

Frame it as part of build-environment hygiene/diagnostics in CI and shared agents, and where the registry lives.

## What the daemon is, briefly The Gradle daemon is a long-lived background JVM that stays warm between builds so JIT-compiled code, the configured project model and caches survive. Because it is a separate process, Gradle ships CLI commands to **inspect** and **control** those processes without you hunting through the OS process list. ## `--status` ``` gradle --status ``` prints a table of the daemons Gradle currently knows about: - **PID** — the OS process id - **STATUS** — `IDLE` (waiting for work), `BUSY` (running a build), or `STOPPED`/`CANCELED` - **INFO** — the Gradle version and uptime Key nuance: `--status` only shows daemons started by the **same Gradle version** you invoke it with. If you have daemons from 8.5 and 8.7 around, `gradle --status` under 8.7 lists only the 8.7 ones. It also omits daemons whose state it cannot reliably read. ## `--stop` ``` gradle --stop ``` sends a **graceful** stop message to every daemon the current version can communicate with. Idle daemons shut down immediately; you cannot target a single daemon by PID through Gradle — it is all-or-nothing for compatible daemons. Stuck or wrong-version daemons are untouched, so for those you use the OS: ``` kill <pid> # unix taskkill /PID <pid> /F # windows ``` ## The registry Both commands are backed by the **daemon registry**, a small binary file at `GRADLE_USER_HOME/daemon/<gradleVersion>/registry.bin` (default `~/.gradle/daemon/...`). Each entry records the daemon's address, PID, and state. `--status` reads it; running builds and `--stop` update it. If the file is corrupt or stale, Gradle prunes dead entries on the next invocation. ## Why it matters In interviews and in CI you reach for these when a build behaves oddly: too many daemons eating RAM, a daemon pinned to an old version, or a hung build. `--status` diagnoses; `--stop` resets cleanly; the OS kill is the last resort.

  • Why might `--status` not list a daemon you know is running?
    Because it only reports daemons started by the same Gradle version, and it omits daemons whose state it can't read. A daemon from a different version, or a stuck/corrupt one, won't appear.
  • Can `--stop` target a single daemon?
    No. It gracefully stops all daemons compatible with the invoking version. To kill one specific PID you drop to the OS (`kill`/`taskkill`).

saying these in an interview costs you the question

  • Claiming `--stop` lets you stop one daemon by PID.
  • Assuming `--status` shows daemons from every Gradle version on the machine.

context

resolving links…