bazel: missing procps causes persistent workers to be repeatedly destroyed

Nixpkgs version

• Unstable (26.11)

Describe the bug

bazel (bazel_9 is what i'm using) uses ps to track memory state of concurrent workers. its not terminal but it massively harms large build performance.

the Bazel package’s runtime tool list omits procps. the corresponding upstream worker-status logic is very clear on why this occurs.

Steps to reproduce

1. Use bazel_9 in a sandboxed Nix derivation’s nativeBuildInputs, without procps.
2. Build a target using persistent workers. I encountered this compiling IntelliJ Community.
3. Inspect Bazel’s java.log: it repeatedly reports Cannot run program "ps", followed by worker destruction with KILLED_UNKNOWN.

i can provide a more precise repro or my original derivation if desired.

Expected behaviour

bazel should be able to manage many workers in its default build environment.

Screenshots

No response

Relevant log output

[com.google.devtools.build.lib.metrics.PsInfoCollector.collectDataFromPs]
Error while executing command ps
java.io.IOException: Cannot run program "ps":
Exec failed, error: 2 (No such file or directory)

Additional context

No response

System metadata

• NixOS, x86_64-linux, Nix sandbox enabled
• nixos-unstable, pinned to 83199d0d373dd3ac2b9a1996b1d0263f76ab7a4c
• bazel_9, version 9.1.1
• Custom derivation using Bazel in nativeBuildInputs

Notify maintainers

---

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

• I assert that this is a bug and not a support request.
• I assert that this is not a duplicate of an existing issue.
• I assert that I have read the NixOS Code of Conduct and agree to abide by it.
• I assert that I have read the automation/AI policy and that this issue report complies with it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

Start with pkgs/by-name/ba/bazel_9/package.nix and inspect the runtime tool list, then reproduce the sandboxed build using persistent workers. Compare the result with Bazel's WorkerProcessMetricsCollector logic and java.log; done means the sandbox can run ps and workers are no longer repeatedly destroyed with KILLED_UNKNOWN.