On 10/19/2018 5:09 AM, Jonathan Billings wrote:
On Fri, Oct 19, 2018 at 01:07:46PM +0200, Simon Matter wrote:
That's really an important point, because those who started using Linux
with Linux/systemd will be bound to Linux/systemd with their knowledge,
switching to a *BSD or other Unix will be difficult. For me, I don't like
to be limited in such ways.
Having worked with the init systems in a bunch of different distros, I
really *loved* having to write a different SysV init script for debian
and RHEL, using different functions and different styles. Also, don't
forget to actually package the Red Hat init scripts as
/etc/rc.d/init.d/, because /etc/init.d is a symlink, while on debian
it is the actual location, and if you weren't careful, your package
would create an /etc/init.d directory and suddenly it's not even found
by the init system.
The first time I had to look at SysV init scripts on a Debian/Ubuntu box
my eyes bled; if systemd had begun from that ecosystem I definitely
would have understood its formation a bit more. But on Red Hat-derived
distros, an initscript for a basic daemon is pretty simple and mostly
boilerplate: copy/paste the sample file, maybe decide what you want to
make tweakable in /etc/sysconfig/, then (if desired) build an RPM
according to best practices.
Virtually everything you might need that isn't provided by the
'functions' file is going to be your own custom logic for your own
daemon, and it turns out that that usually doesn't change in a systemd
landscape, resulting in a lot of workarounds, wrappers, and shell bits
in unit files which would probably be more predictably understood in a
single shell script to begin with.
Building a single init script that works across ALL Linux distributions
(and other unices) is indeed painful and ugly, so if a vendor wanted to
make a declarative config file and wash their hands of, that's
understandable. But the same goes for an xinetd.conf snippet, or any
other service manager of the same ilk. And making a boilerplate /Red
Hat-specific /init script is trivial.
Heck, there was even an argument
about which shell they're run with. And it was always fun when shell
bugs cropped up in init scripts. A vendor writes an init script using
bash features that aren't in another distro, but it still uses the
#!/bin/sh shebang so you get really weird and difficult-to-diagnose
startup errors.
That's a larger *nix issue. As a proponent of dash on EL systems, I
definitely think ensuring bashisms are called out and that /bin/sh means
/bin/sh is probably a Good Thing.
And heaven forbid you actually want to *SEE* any shell errors.
Nothing is ever captured in any logs, you have to be physically
looking at a console (be it a glass terminal or serial line) to
capture the error.
The /sbin/service command is just a shell script. I'd suggest a patch to
send stderr/out to logger as well if I thought it would be accepted.
(And *manually executing* an init script with direct call was something
we were already supposed to be deprecating; the service command was the
standard environmental interface.)
Frankly, I've had a lot more problems debugging mysterious systemd-based
startup failures than I ever had in a properly-written Red Hat init
script. (Again, vendor-agnostic init scripts can be hot messes, but
that's them...)
-jc
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
