[CentOS] OT: systemd Poll

Mon Apr 10 18:26:52 UTC 2017
Jonathan Billings <billings at negate.org>

On Sun, Apr 09, 2017 at 09:30:20AM +0100, J Martin Rushton wrote:
> For those of us with (in my case) over 30 years in the industry, reading
> init scripts is trivial and at least we can see what is going on and fix
> problems quickly.

As someone who has both debugged and written many init scripts, I'm a
big fan of the way systemd does things.  Every distro provided their
own shell functions, so you ended up with a debian init script, a
redhat init script, and usually some weird "kinda works everywhere"
init script that used neither and reinvented the wheel.

Quite often, what was going wrong was *NOT* apparent by glancing at
the init script.  How do you enforce limits on the service?  Run
ulimits in the script?  The service starts fine if you run
'/etc/rc.d/init.d/myservice start', but then if you run
'service myservice start', it fails.  On top of that, there's no
journal so you can't even *SEE* why it is failing during boot unless
it is kind enough to write an error to the console.  Hope you have a
crash cart!

Also, how configurable is the init script?  You had to hope that
upstream was smart enough to use environment variables that were
sourced from /etc/sysconfig/servicename.  Sometimes I had to do evil
things like put executable code into /etc/sysconfig/servicename which
fixed problems with the init script.

Also, that reminds me, there's no simple way to override some or all
of a packaged init script, except to provide your own alternative init
script that had a different name.  And don't get me started on the
terrible startup sequence rules.  I've seen several people who have
edited the init script itself and then had it replaced by a yum
update, breaking their service.  The RPMs don't mark the init script
as a config file.

>  Some vague, poorly documented, data file which is
> interpreted by a black box is the sort of joy one expects from the
> murkier regions of Redmond not the sunnier climes of Carolina.

I don't know... I find the unit syntax pretty simple to read.  It says
what processes are going to be run, what user it'll run under, you can
see what order it wants to be run, etc.  There are dozens of man pages
for systemd, each with examples.

Don't get me wrong, I have a lot of anger about some of the stuff that
systemd does.  But lets not reminisce about SysVinit as if it was
anything but a horrible mess.  systemd's best feature is that it
finally makes managing services better.

Jonathan Billings <billings at negate.org>