skip to content

How do you inspect which Gradle daemons are alive and in what state, and how do you force them to stop? When would you reach for each command?

level: middleimportance: should knowfreq 38%

answer

  1. --status = list PID/version/IDLE-BUSY
  2. --stop = terminate all (this version)
  3. version-scoped
  4. manual hammer vs idletimeout auto-timer
  5. verify tuning, clear orphans

basics

~10 s

gradle --status lists live daemons with their PID, Gradle version and status (IDLE/BUSY). gradle --stop terminates all daemons for that Gradle version. Use --status to inspect, --stop to clear stale/misbehaving daemons immediately.

solid answer

~40 s

`gradle --status` prints the daemons Gradle knows about for the current version: PID, Gradle version, and whether each is `IDLE` or `BUSY`. It's how you confirm tuning took effect (idle daemons aging out per your `idletimeout`) or spot orphaned daemons left after a JVM-args change. `gradle --stop` force-terminates **all** daemons for that Gradle version right away — the manual override when you don't want to wait for `idletimeout`. Typical uses: clearing fat idle daemons before running something memory-hungry, recovering from a wedged/corrupt daemon, or getting a clean slate after switching heap/JDK settings. Note `--stop` is version-scoped — daemons from a different Gradle version aren't touched. Together they're the inspect/clear pair that complements the automatic idle-shutdown timer.

code

bash · 2 lines
bash
./gradlew --status   # inspect: which daemons, IDLE or BUSY
./gradlew --stop     # clear: kill all daemons for THIS Gradle version

go deeper

for a junior

Know --status lists daemons and --stop kills them.

for a middle

Explain IDLE/BUSY states, when to inspect vs clear, and version scoping of --stop.

for a senior

Use --status to diagnose orphaned/incompatible daemons and pair --stop with idletimeout tuning intentionally.

for a principal

Bake daemon hygiene (timeout policy + when scripts call --stop) into standardized build-environment tooling across teams.

## Two commands, two jobs ### `gradle --status` — inspect Lists the daemons for the **current Gradle version**, e.g.: ``` PID STATUS INFO 12345 IDLE 8.7 12346 BUSY 8.7 ``` Use it to: - Confirm your `org.gradle.daemon.idletimeout` change is working — idle daemons should disappear after the window you set. - Spot **orphaned** daemons left idle after an incompatible JVM-args/JDK change. - See whether a daemon is currently BUSY before you decide to stop it. ### `gradle --stop` — clear Immediately terminates **all** daemons for the current Gradle version. It's the manual override for the idle timer: ```bash gradle --stop ``` Reach for it when: - You want a **clean slate** after changing heap/metaspace/JDK and don't want stale daemons lingering until their idletimeout. - A daemon is **wedged or behaving oddly** and you want to kill and re-fork. - You need to **free memory now** before a heavy task, rather than waiting for idle shutdown. ## Important scoping detail Both commands are **scoped to the Gradle version** you invoke them with (typically via the wrapper). If you have daemons from multiple Gradle versions, `--stop` from version A won't touch version B's daemons — run it per version (or use the matching wrapper) to clear them all. ## How they relate to idletimeout - `idletimeout` is the **automatic** reclamation timer. - `--stop` is the **manual** reclamation hammer. - `--status` is the **observability** window to verify either is doing what you expect. A healthy workflow: tune `idletimeout` for the steady state, use `--status` to verify, and `--stop` for one-off cleanups.

  • You ran gradle --stop but a daemon survived. Why?
    --stop is scoped to the Gradle version you invoked. A daemon from a different Gradle version is untouched; run --stop with the matching wrapper/version to clear it.
  • How would you confirm a shortened idletimeout is actually working?
    Finish a build, wait past the new idle window, then run gradle --status — the previously IDLE daemon should no longer be listed because it shut itself down.

saying these in an interview costs you the question

  • Thinking --stop clears daemons across all Gradle versions at once.
  • Believing --status can terminate daemons (it only reports).
  • Stopping a BUSY daemon mid-build without realizing it aborts that build.

context

resolving links…