[CentOS] OT: systemd Poll

[ken]

On 04/10/2017 08:13 PM, Bruce Ferrell wrote:
> 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. 

And I have to wonder, why in /usr/lib/systemd/system/ is there a file 
named -.slice ??  Didn't anyone see a problem with this...? or countless 
possible problems?  Doesn't instill confidence.