processkit crate brings kill-on-drop child process control to Rust

A hung test is annoying; a child process that slips past Ctrl-C and keeps running is worse. processkit surfaced with a promise Rust CLI authors and automation builders have wanted for years: whole-tree kill-on-drop semantics, so a parent can go away without leaving descendants behind to haunt the next run.

This week’s Rust ecosystem roundup, This Week in Rust 656, published on June 17, 2026, listed processkit 1.0 as async process tree management. The crate describes itself as async child-process management for Rust and Tokio, and it goes beyond spawning commands. Its feature set includes run-and-capture, streaming, shell-free pipelines, timeouts, cancellation, and supervision, all aimed at making subprocess handling feel predictable instead of fragile.

What makes processkit stand out is that the no-orphan guarantee is backed by the kernel rather than by hopeful cleanup code. On Linux, it can lean on cgroup v2, where the kernel documents cgroups as a tree structure and says every process belongs to one cgroup. On Windows, it can use a Job Object, which Microsoft documents as a way to manage groups of processes as a unit, with termination of the job taking the associated processes with it. On POSIX, it falls back to process groups, the old shell job-control mechanism whose orphaned-group behavior is spelled out in the man pages.

That matters because child-process control is one of those problems that looks small until it escapes into CI, test runners, build scripts, or long-lived dev tools. A background daemon, a spawned grandchild, or a shell pipeline that outlives the parent can leak state across runs and make failures look random. processkit’s approach is to make lifetime control explicit and kernel-assisted, which cuts down on the signal juggling and ad hoc shell logic that usually piles up around process supervision.

The crate also fits neatly into Tokio’s world. Tokio’s `process` module is an asynchronous implementation of process management, and its `Command` type mirrors `std::process::Command`, so processkit lands in familiar territory for anyone already building async Rust services and tooling. The project’s GitHub repositories frame it the same way: `ZelAnton/ProcessKit-rs` calls itself a Rust process management library, while `ZelAnton/ProcessKit` describes the broader ProcessKit family as async child-process management libraries.

That is the real shift here. processkit is not just another process crate; it is an attempt to make orphaned subprocesses stop being part of the everyday cost of shipping Rust tools.