A new filesystem for pidfds [LWN.net]

A new filesystem for pidfds

Posted Mar 13, 2024 18:05 UTC (Wed) by ianmcc (guest, #88379)
Parent article: A new filesystem for pidfds

Why wasn't /proc/pid reused for this? If there was a way to access /proc without it being mounted, then that would seem to solve some other problems.

to post comments

A new filesystem for pidfds

Posted Mar 13, 2024 21:46 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (6 responses)

According to pidfd_open(2), opening /proc/pid *does* give you a pidfd, but it has a few minor restrictions compared to a properly-obtained pidfd (from pidfd_open(2) or clone(2)). I am uncertain of the reason for those restrictions, but it does look like there was a conscious decision to create two different kinds of pidfd. Maybe someone who actually knows what they're talking about can shed further light on this issue.

A new filesystem for pidfds

Posted Mar 13, 2024 22:49 UTC (Wed) by fraetor (subscriber, #161147) [Link] (5 responses)

IIRC the main difference is that you can only get the pidfd from /proc after the process has been created. This leaves (at least a little) time for the desired process to exit and the pid to recycled for another process.

This race condition is one of the main things pidfds exist to fix, so it's better to get the fd immediately at process creation.

A new filesystem for pidfds

Posted Mar 14, 2024 1:46 UTC (Thu) by magfr (subscriber, #16052) [Link]

But why is that a hindrance for clone to return an fd in procfd? Sure, there might not be any link to it left under /proc but that is no problem, is it?

A new filesystem for pidfds

Posted Mar 14, 2024 4:29 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (3 responses)

A pid can only be recycled after the parent process called waitpid or related methods. Thus in a properly written application there should be no race when using the pid.

However that does complicate the code especially when one writes a library that wants to start external process as arranging for waitpid call becomes problematic.

A new filesystem for pidfds

Posted Mar 14, 2024 8:14 UTC (Thu) by roc (subscriber, #30627) [Link] (1 responses)

It's extra-annoying because waitpid() only has a limited set of options for what you can wait for. You can't choose an arbitrary set of processes to wait on.

It's also a problem that only the parent can do the wait. You can't pass ownership of the subprocess to another process this way.

A new filesystem for pidfds

Posted Mar 19, 2024 7:04 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

> It's also a problem that only the parent can do the wait. You can't pass ownership of the subprocess to another process this way.

Technically, you can sorta kinda hand the ownership to another process by passing PR_SET_CHILD_SUBREAPER to prctl(2), but there are so many caveats with this method that it's not even funny:

* The destination process must be an ancestor of you.
* You have to orphan the child process, which means you have to do a double-fork.
* It is a global (process-wide) flag on the destination process, which makes it assume ownership of all orphaned processes under it, not just your particular process. If the destination does not periodically call wait, it will leak zombies until it dies.
* It is really meant to be used by things like systemd. If you are not implementing something that resembles systemd, there are probably other pitfalls I'm unaware of.

In short: This may be reasonable if you are trying to make an entirely self-contained self-managing all-singing all-dancing daemon that does all of its own bookkeeping, sessions, etc., but in practice you're probably better off configuring systemd to do those things for you instead, unless you're one of those sysvinit-or-death people.

A new filesystem for pidfds

Posted Mar 14, 2024 9:52 UTC (Thu) by bluca (subscriber, #118303) [Link]

That only helps if it's the parent process that needs to reliably identify another process. That is not the case, and hasn't been for years.