A new filesystem for pidfds [LWN.net]

A new filesystem for pidfds

Posted Mar 14, 2024 8:14 UTC (Thu) by roc (subscriber, #30627)
In reply to: A new filesystem for pidfds by ibukanov
Parent article: A new filesystem for pidfds

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.

to post comments

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.