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

[Nick Holland]

On 12/6/23 17:27, Ron / BCLUG wrote:
> 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.

Sure.  If you design things badly, and then implement them badly,
you may well wish the OS made your bad decisions less 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?)

so... systemd has issues.  So lets create something new to deal with
those issues!  Out Of Memory killers are just a bad idea. "Hey, my
system is out of memory (due to bad applications leaking memory), let's
start  killing processes!" -- this can't reliably end well.  Sometimes,
it is best to just let your system wedge and stop doing damage, than to
let the system continue to inflict more damage, "but uptime is great!".

And that's a classic Linuxism.  Rather than fixing the actual problem,
make the system more complex, introduce three problems for every one
solved, and call it progress, and if you are opposed, you are standing
in the way of progress.
  
>> 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?

I do believe AIX does as well.  Seemed to tag the parent's
PID as part of child PIDs, and a really big PID space.  Very
simple, really, other than a lot of digits in the PID.
  
> With OpenBSD & NetBSD, good luck, I guess?

Or perhaps people writing for OpenBSD and NetBSD understand that
process IDs get reused, and if that matters to you, you are Doing
It Wrong.

For the record, OpenBSD quit tracking processes by PID files a long
time ago, because when you "kill $(cat /var/run/httpd.pid)", you
really have no idea what you are killing.  You have taken what
should have been used as a useful hint and promoted it to gospel.
(for compatibility, some apps still create PID files in OpenBSD,
but the system doesn't depend upon them being accurate).

And the cool thing, in Unix, there are existing other ways to keep
track of what process owns what.

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

Sounds like they are addressing problems created by systemd to me.

We've all heard stories of people with allergy problems living in the
midwest, moving to the desert, say, Arizona, and reporting how much
better they feel now that they don't have all that pollen in the air.
And then you hear about people in Arizona who don't like sand for a
front lawn, who are convinced that the ground around their house
should be green, and tree covered...so they start watering the sand
and planting the very plants that prompted them to move to Arizona in
the first place.

This is exactly what I see going on with Linux.  A bunch of
Frustrated Windows Users jumping over to the "superior" Linux
platform...and reinventing Windows there...badly.  I'm quite
convinced if they could make changes to Windows willy-nilly like
they do in Linux, they would have stayed there.

I'm not saying these people are fools, some of them are outright
brilliant, but they aren't versed in the Ways of Unix, nor are they
motivated by the "Simpler is Better" philosophy.  It's fun to see
Your Project highlighted in a new Linux kernel.  It is boring to
solve a problem with existing tools.

There are a bunch of ways of tracking processes in the standard
Unix tool set, I really doubt it was necessary to reinvent that
wheel. Run application as a separate user (or the same user, if
appropriate).  Use setproctitle(3) to let tasks advertise what
they want (or don't want) other tasks to know about them.
Establish some form of communications between tasks.  *Design
your tasks properly*, don't just rebuild the OS to support your
bad apps.

I'm not saying Unix should be unchanging -- the world has changed
a lot since 1970, it does need to be evolved to fit.  But the
practical difference between the Windows thrashing design and the
Linux thrashing design is getting waaay too small for my tastes.
Linux does too much reinventing nice round wheels without
thinking about why the wheel was round in the first place.  And
too often in Linux, rather than replacing an "inferior" wheel,
they add Yet Another Wheel to the car, because no Linux tool ever
just replaces an old tool, they co-exists, conflict, stomp on,
and generally make life a nightmare.  How many file systems does
Linux have?  How many network filtering/firewall tools?  How
many ways to configure the bloomin' network (this one is pathetic
in my mind -- there's no excuse for what they have done here).

This is a general Open Source problem -- it's far more fun to add
a whole new feature than to make existing features suck less (or
even work), and REMOVING a bad idea is entirely forbidden, it
might offend someone!


Linux, *BSD, and Windows are Operating Systems -- they load
programs, supervise the running of programs, control access to
system resources, etc.  If you are dealing with your OS enough
to get passionate about low level features of the OS, I would
argue something is really broken, as the OS is now becoming
front and center, rather than the applications you are running
on it.


As for OpenBSD's use in the real world...  more-or-less by design,
no one knows.  I run an OpenBSD mirror, so I am closer to data
about that than most people.  I have no idea how to digest it, other
than if my mirror goes down, I hear about it, so people care.
That's good enough for me.

However, the influence is quite obvious.  Microsoft
has made it clear a number of times that they watch OpenBSD quite
closely.  I remember long ago, reading a MS blogger saying
something to the effect of "they had looked at the W^X technology
for a time, but doubted it could be used in a real OS, until
OpenBSD showed that yes, it could". Take a look at the donations
page -- there's obviously a lot of corporate entities that see a
value in it to help keep it going.  And of course, now that MS
is on-board, I can say /every/ major OS now includes OpenSSH,
and OpenBSD product.


I know a guy who argued that The Beetles were the Greatest
Musicians Ever because they sold more records than anyone else.
No other musician was anywhere near as good.  I didn't have the
heart to point out to this aspiring musician that by his own
measure, he was worse than a failure, because not only had he
not made any money or sold any records, he actually paid to
have people record his music.

If popularity is the measure of an OS, Linux is a pathetic
"Also Ran" behind Windows.  So I suspect that really isn't the
measure we want to use.

In OpenBSD's case, popularity was never a goal, that was the
topic of the 4.2 release theme.  OpenBSD is about security
and correctness, and reality is -- no one gives a rat's butt
about either.  They care about cost (free as in beer), bling,
not changing the existing process and programs, and what will
look good on the resume for the next job.  Security can often
be demonstrated to be most people's and most company's LAST
priority.  Not "low on the list", but LAST, as in "if I have
to change anything I'm not going to use it" last.  So yeah,
OpenBSD will never be a "major player", everyone involved
knows that.

Nick.