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
• 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.