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]