Tracking Issue for linux_pidfd

Feature gate: #![feature(linux_pidfd)]

This is a tracking issue for Linux-specific extension methods allowing to obtain process file descriptors for processes spawned with the standard Command API.

Public API

// std::os::linux::process

pub struct PidFd;

impl PidFd {
   pub fn kill(&self) -> Result<()> {...}
   pub fn wait(&self) -> Result<ExitStatus> {...}
   pub fn try_wait(&self) -> Result<Option<ExitStatus>> {...}
}

impl AsRawFd for PidFd {}
impl FromRawFd for PidFd {}
impl IntoRawFd for PidFd {}

// sealed trait, implemented for std::process::Child
pub trait ChildExt {
    fn pidfd(&self) -> Result<&PidFd>;
    fn into_pidfd(self) -> Result<PidFd, Self>;
}

// sealed trait, implemented for std::process::Command
pub trait CommandExt {
    fn create_pidfd(&mut self, val: bool) -> &mut process::Command;
}

Steps / History

Implementation: Add Linux-specific pidfd process extensions #77168, Add Linux-specific pidfd process extensions (take 2) #81825
replaced use of clone3: open pidfd in child process and send to the parent via SOCK_SEQPACKET+CMSG #113939
if available use a Child's pidfd for kill/wait #117957
Add PidFd::{kill, wait, try_wait} #124101
Use pidfd_spawn for faster process spawning when a PidFd is requested #126827
use PIDFD_GET_INFO ioctl when available #150412
Final commenting period (FCP)
Stabilization PR

Unresolved Questions

How can we properly open a pidfd for the new process? The current implementation using a manual clone3 means we can't safely call libc in the child: cargo 1.56 beta hang when run inside Gentoo's sandbox #89522 (comment)
- pidfd_open may work, but it has conditions on avoiding pid-recycling races.
should Child::pidfd(&self) be removed? It can lead to Child::wait returning errors instead of a saved exit status if PidFd::wait obtains the exit status first, which may be surprising behavior.

Rollup merge of rust-lang#81825 - voidc:pidfd, r=joshtriplett

The PR adds support for obtaining PidFds, but you can't actually do anything with them. Do we want additional methods on PidFd in std to wait, send signals, obtain the /proc directory etc. or should that be left to 3rd party crates?

Rollup merge of rust-lang#81825 - voidc:pidfd, r=joshtriplett

@asomers

With #150412 I think we should be fairly close to be able to stabilize this for linux.

But I recall that FreeBSD has a similar but more limited API. CC @asomers @MikaelUrankar
Would it make sense to expand this to a common linux + freebsd feature?
I'm not seeing a way to use posix_spawn while still obtaining one of those FDs. And no way to get the exit status from an fd.

@the8472

Sorry, I've not been in-the-loop on this feature. But regarding your questions, @the8472 :

It's not currently possible on FreeBSD to spawn a new process and get a pidfd without cloning the process's virtual address space. That is, you must do pdfork + exec. There's nothing like pdposix_spawn. Using pdfork + exec works, but it's a little less efficient.
There is indeed a way to wait for a child based on its pidfd. But instead of using wait4, you must use kevent with EVFILT_PROCDESC. See https://man.freebsd.org/cgi/man.cgi?kevent(2).

Rollup merge of rust-lang#150412 - the8472:pidfd-spawn, r=tgross35

@asomers

We talked about this in today's libs-api meeting. We'd be interested in having this on FreeBSD under std::os::freebsd::process too if possible so that it's a N=2 API to inform portability.

@asomers @MikaelUrankar would you be interested in implementing it?

Unrolled build for #150412

@the8472

I'll give it a shot, @the8472 . And BTW, I realized that it's not necessary to use kevent like I originally thought. The wait-like functionality can be provided by using poll or select on the process file descriptor.

How come PidFd::kill is hardcoded to use SIGKILL/PidFd::send_signal isn't public? I think it would be more valuable if you were able to send any signal (or at least valid ones from an enum).

Navigation Menu

Repository navigation

Tracking Issue for linux_pidfd #82971

Public API

Steps / History

Unresolved Questions

52 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for linux_pidfd #82971

Description

Public API

Steps / History

Unresolved Questions

Activity

the8472 commented on Mar 16, 2021

52 remaining items

the8472 commented on Jan 5, 2026

brauner commented on Jan 5, 2026

the8472 commented on Jan 5, 2026

asomers commented on Jan 5, 2026

the8472 commented on Jan 6, 2026

asomers commented on Jan 7, 2026

Zorbatron commented on Apr 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions