Clippy lint · Suspicious · checked with Clippy 0.1.99

clippy::zombie_processes: spawned process is never `wait()`ed on

What it meansLooks for code that spawns a process but never calls wait() on the child. It is in the suspicious group and warns by default.

What you see

warning: spawned process is never `wait()`ed on
 --> main.rs:5:14
  |
5 | let _child = Command::new("ls").spawn().expect("failed to execute child");
  |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: consider calling `.wait()`
  = note: not doing so might leave behind zombie processes
  = note: see https://doc.rust-lang.org/stable/std/process/struct.Child.html#warning
  = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#zombie_processes
  = note: `#[warn(clippy::zombie_processes)]` on by default

Real output of Clippy 0.1.99 (Rust 1.99) on the example below. Names and line numbers in yours will differ.

Does it matter?

As explained in the standard library documentation, calling wait() is necessary on Unix platforms to properly release all OS resources associated with the process. Not doing so will effectively leak process IDs and/or other limited global resources, which can eventually lead to resource exhaustion, so it’s recommended to call wait() in long-running applications. Such processes are called “zombie processes”. To reduce the rate of false positives, if the spawned process is assigned to a binding, the lint actually works the other way around; it conservatively checks that all uses of a variable definitely don’t call wait() and only then emits a warning. For that reason, a seemingly unrelated use can get called out as calling wait() in help messages.

Code that is most likely wrong or useless. Warns by default.

How to fix it

Clippy does not fix this one automatically (its suggestion may change behaviour, so it only shows it). Change the code by hand:

Flagged

use std::process::Command;

let _child = Command::new("ls").spawn().expect("failed to execute child");

Write this instead

use std::process::Command;

let mut child = Command::new("ls").spawn().expect("failed to execute child");
child.wait().expect("failed to wait on child");

Turn it off, or on

Allow it where it does not fit your code, as narrowly as you can:

On one item

#[allow(clippy::zombie_processes)]
fn my_function() { /* ... */ }

Whole crate (Cargo.toml)

[lints.clippy]
zombie_processes = "allow"

One run

cargo clippy -- -A clippy::zombie-processes

The [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.

Suspiciousgroup

warndefault level

nofixed by cargo clippy --fix

1.83.0added in Rust

Clippy's own documentation

What it does

Looks for code that spawns a process but never calls wait() on the child.

Why is this bad?

As explained in the standard library documentation, calling wait() is necessary on Unix platforms to properly release all OS resources associated with the process. Not doing so will effectively leak process IDs and/or other limited global resources, which can eventually lead to resource exhaustion, so it’s recommended to call wait() in long-running applications. Such processes are called “zombie processes”.

To reduce the rate of false positives, if the spawned process is assigned to a binding, the lint actually works the other way around; it conservatively checks that all uses of a variable definitely don’t call wait() and only then emits a warning. For that reason, a seemingly unrelated use can get called out as calling wait() in help messages.

Control flow

If a wait() call exists in an if/then block but not in the else block (or there is no else block), then this still gets linted as not calling wait() in all code paths. Likewise, when early-returning from the function, wait() calls that appear after the return expression are also not accepted. In other words, the wait() call must be unconditionally reachable after the spawn expression.

Example

use std::process::Command;

let _child = Command::new("ls").spawn().expect("failed to execute child");

Use instead:

use std::process::Command;

let mut child = Command::new("ls").spawn().expect("failed to execute child");
child.wait().expect("failed to wait on child");

From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.

Up next

Also worth your time

Did this answer your question?