[Semibug] SystemD is literally the kitchen sink of Linux ; Linux starting to feel more and more alien as the years go on

[Ron / BCLUG]

Kyle Willett wrote on 2023-12-06 13:59:

> Now to quote the article: "Most internal process tracking is now 
> using PIDFDs rather than PIDs when running on a supported kernel."
> 
> What the heck is a PIDFD instead of a PID.

 From 
https://kernel-recipes.org/en/2019/talks/pidfds-process-file-descriptors-on-linux/

> Due to how pid allocation works the kernel is free to recycle PIDs 
> once a process has been reaped.

Makes sense.

> As such, PIDs do not allow another process to maintain a private, 
> stable reference on a process.

Uh-oh. That could be bad.


> On systems under pressure it is thus possible that a PID is recycled 
> without other (non-parent) processes being aware of it. This becomes 
> rather problematic when (non-parent) processes are in charge of 
> managing other processes as is the case for system managers or 
> userspace implementations of OOM killers.

Sounds like a real-world problem that's being addressed. Not that I've
encountered it. (That I'm *aware* of - would I even know?)



> All Unix users know what a PID is it is universal but Linux has to be
> different.

On page 6 of the embedded slide show at the link above, there's a
section called "Prior Art", and in that list are:

* Illumos: similar userspace tools
* OpenBSD, NetBSD: no private, stable process handles
* FreeBSD: procdesc:pdfork(), pdgetpid(), pdkill()
* Linux: forkfd(), CLONE_FD


So, looks like FreeBSD and Illumos have similar mechanisms?

With OpenBSD & NetBSD, good luck, I guess?


At least, that's how I'm reading it; could well be wrong.


TL;DR - it appears that PIDFDs are addressing a real-world problem