[CentOS] What are the differences between systemd and non-systemd Linux distros?

Fri Oct 19 19:18:39 UTC 2018
Japheth Cleaver <cleaver at terabithia.org>

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...)