On 04/10/2017 03:20 PM, Pete Biggs wrote:
I must admit that I skipped through the first and second stages - I
never found creating init scripts a joy and instead opted to write my
own scripts that I launched via inittab. As such, I welcomed the
simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you
still ridiculing it, violently opposed to it, or have you mellowed to it?
It is what it is.
I can see that systemd may not look as straightforward as init scripts,
but it has been clear for a while that SysVinit is generally not really
fit-for-purpose. Things like the mystic incantations embedded in
comments at the top to try and make chkconfig work properly, or the
lack of a consistent approach to configuring parameters (are they
embedded in the script? In /etc/sysconfig? The package's own config
files?).
The fact that there was at one point multiple solutions to the problem
(with systemd eventually becoming the accepted one) and that no dev is
really going to voluntarily go through the pain and abuse of
implementing something new like this shows that it really was thought
to be necessary.
I think what is/was the issue is the abrasive way that some of it was
done. It seems to have put people's backs up no end and makes them
predisposed to find fault with it.
It's just different, that's all. It does the job it was designed to do.
It even copes with legacy init scripts, so you can still use them if
you want.
And I remember when these new fangled init scripts first appeared - boy
did everyone find them confusing and hated them.
P.
My first *IX system had only /etc/inittab and I had to manually add and configure inetd. Next generation used the bsd init system... Monolithic. No process start/stop, but I
understood it. Then SystemV came along; Individual processes could be started, stopped, and queried. The came the function file and THAT was a complete mess... Every distro
developer had his own idea of what functions were needed.
In all three of those cases, there was a single, simple start up entity. That was the literal binary program init. It read /etc/inittab and used that to handle process management
and those management processes were completely transparent. Standardized, well known locations were used. It was considered to be a not just good practice, but excellent practice
to do so. It wasn't commonly done, but it was relatively simple to swap between them too.
The current crop of system initialization systems, do everything possible to obscure the details of operation... Boot status on the console? Nope, obscured. Processes logged to
standard places? Nope, someone might hijack the logs (we had a technique for that... remote logging, but that isn't important enough to make work... Too much trouble).
The bottom line seems to be, "I've looked at this, and I know better than 20, 30 years of experience, so throw it all out and do it my way"... And if things get broken in the
process... Oh well, that's progress.
I've had my init system lose communication with the desktop gui and decide to reboot my system. Yes, systemd did that. dbus got an upgrade and was restarting so systemd rebooted
my system.
While not directly a systemd problem, I've haddistro builds of apache that didn't work because of some patch "needed" so systemd could manage apache (We need systemd hooked so
deeply into every process now?!). Yes, each of these was corrected... But they didn't need to happen and NEVER happened with earlier init systems.
The concepts in upstart, launchd, and systemd are mildly interesting to me and probably more so to others. The implementations of the ideas have been poorly thought out and
tested. They cause so much trouble for me as to make them worthless to me. When complaints are registered, the response has often been "if we don't force it, it will never be
tested". Completely unacceptable.
This is MY issue with the new shiny toy. Heedless and needless system breakage by an escaped lab rat.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
