Repository navigation
Tracking Issue for linux_pidfd #82971
Description
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
clone3means we can't safely call libc in the child: cargo 1.56 beta hang when run inside Gentoo's sandbox #89522 (comment)pidfd_openmay work, but it has conditions on avoiding pid-recycling races.- fixed by open pidfd in child process and send to the parent via SOCK_SEQPACKET+CMSG #113939
- should
Child::pidfd(&self)be removed? It can lead toChild::waitreturning errors instead of a saved exit status ifPidFd::waitobtains the exit status first, which may be surprising behavior.
Reacted by Stepan Koltsov, Diana, zopsicle, José Luis Cruz, Matthew Scheffel, Karol Baraniecki and Charles Hall
Activity
Rollup merge of rust-lang#81825 - voidc:pidfd, r=joshtriplett
the8472 commentedon Mar 16, 2021
The PR adds support for obtaining PidFds, but you can't actually do anything with them. Do we want additional methods on
PidFdin std to wait, send signals, obtain the/procdirectory etc. or should that be left to 3rd party crates?Rollup merge of rust-lang#81825 - voidc:pidfd, r=joshtriplett
Rollup merge of rust-lang#81825 - voidc:pidfd, r=joshtriplett
Rollup merge of rust-lang#81825 - voidc:pidfd, r=joshtriplett
Rollup merge of rust-lang#81825 - voidc:pidfd, r=joshtriplett
52 remaining items
the8472 commentedon Jan 5, 2026
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.
brauner commentedon Jan 5, 2026
the8472 commentedon Jan 5, 2026
asomers commentedon Jan 5, 2026
Sorry, I've not been in-the-loop on this feature. But regarding your questions, @the8472 :
pdfork+exec. There's nothing likepdposix_spawn. Usingpdfork+execworks, but it's a little less efficient.wait4, you must usekeventwithEVFILT_PROCDESC. See https://man.freebsd.org/cgi/man.cgi?kevent(2).Rollup merge of rust-lang#150412 - the8472:pidfd-spawn, r=tgross35
Rollup merge of rust-lang#150412 - the8472:pidfd-spawn, r=tgross35
Rollup merge of rust-lang#150412 - the8472:pidfd-spawn, r=tgross35
Rollup merge of rust-lang#150412 - the8472:pidfd-spawn, r=tgross35
Rollup merge of rust-lang#150412 - the8472:pidfd-spawn, r=tgross35
the8472 commentedon Jan 6, 2026
We talked about this in today's libs-api meeting. We'd be interested in having this on FreeBSD under
std::os::freebsd::processtoo 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
asomers commentedon Jan 7, 2026
I'll give it a shot, @the8472 . And BTW, I realized that it's not necessary to use
keventlike I originally thought. Thewait-like functionality can be provided by usingpollorselecton the process file descriptor.Zorbatron commentedon Apr 15, 2026
How come
PidFd::killis hardcoded to useSIGKILL/PidFd::send_signalisn'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).