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
 			[log in to unmask]