Open
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
- 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 toChild::wait
returning errors instead of a saved exit status ifPidFd::wait
obtains the exit status first, which may be surprising behavior.