My reminisces and tuppence-worth:
On Sat, 23 Jan 2021, ~Stack~ wrote:
One thing people tend to overlook in these conversations is that systemd was
clearly not meant to help SysAdmins - the fact that does is a by product. The
point was to help system builders and integrators. EG: the people building
the distro that others use; the ones who try to make all of the sub-services
play nice with each other so that the end user can just click around on a
mouse.
You can think of SystemD as the the low level communication of services that
not a whole lot of people (developers nor users) want to do but everyone who
uses a desktop or server depends on to work- it's at the integrator level
where SystemD starts to shine. It helps a lot of the underpinning
communications where most users don't ever dare to tread. Those dark tunnels
where experienced SysAdmins have their eyes gloss over at the dread they
encountered upon their last traversal.
Those places.
Because getting all the services to talk to one another is incredibly
difficult. Speaking as someone who used to do a bunch of dbus level
programming to get services to talk to each other, the old InitV methods
sucked. It was painful. And every time there was a new service that did
things differently, it made my work harder. I particularly recall in ~2008
tracing out an issue with a kernel notification to a network card that caused
Pidgin to flip out and spam the dbus to the point of crashing other
completely unrelated services because of a custom plugin...gah...I was down
reading hex code off the kernel processes to figure that out...and it still
gives me wake-up-screaming-nightmares...But all the users knew was that their
music player would cause a kernel panic - they had no idea it was even a
plugin on Pidgin that was doing it because why would Pidgin (a chat program )
care if a music file was played? And what did that have to do with crashing
the kernel?
I wish I had read something like this at the time.
It would have given me a better idea of what systemd was about.
I'm somewhat old school (I am still using twm as my window manager* over a
decade later) so I don't know why anyone would want this new-fangled DBus
thing that, as you say, lets a chat program addon cause a music player to
crash the kernel.
For release after release we had to hack/patch an init script.
IIRC this was Red Hat 4 and 5, and I don't remember all the details,
so what follows may be a little off: We had to make ypbind run on
a fixed port so that nfsd didn't fail because something else had
grabbed the port first (or was it the other way around ?)
With that experience I wont believe you if you tell me that a complex
C program handling lots of signals and processes is safer than a shell
script. I know which one I can hack sucessfully and have enough smarts
to consider whether what I did was secure.
From what yo say, systemd might have been the right answer to my
original problem, but if Red Hat couldn't get around to fixing the
nfsd/ypbind conflict, could I expect them to make code 10 times
(or maybe a 100) more complex any more reliable ?
By the sound of it Larry Linder, who started this discussion, finds
that chat programs and music players don't help the productivity
of his machine-tool shop either. If D-Bus is a problem why would
he want a complex system that appears to exist to allow it ?
* No, I do not want a "desktop environment". My windows were either
firefox or xterm's sshd into other machines - sometimes a hundred,
fired up in batches of twenty.
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
