[clue] systemd - uh, wot's the deal?

[Michael J. Hammel]

On Sat, 2015-10-31 at 10:42 -0600, Sean LeBlanc wrote:
> I've seen murmurings from the 
> bowels of the Internet (mostly on Diaspora) about systemd, and that's it 
> is controversial, etc.

We build a system starting with debootstrap utilizing upstream Ubuntu
14.04 packages.  Our system uses SysV init scripts.  Ubuntu 14.04's
upstart init system handled those fine.

Recently they pushed systemd as the primary init system.  You can still
use upstart but you have to specifically request it.  So I figured I
better start looking into systemd.

Yuck.

Systemd is fine for systems that run large numbers of background daemons
that have many interdependencies.  It provides replacement for a number
of operations that might happen at startup or during the system's
uptime.  It claims to have a simplified scripting mechanism based on INI
files.  

What I found was a limitation to 5 minutes for any startup daemon (that
may be configurable but that limit is where I'm at now).  Our system
cannot guarantee all systems are up in that time.  I also have a single
init script that serializes the loading of drivers and starting of
daemons.  Systemd would suggest splitting that into multiple
configurations.  My solution is to write a wrapper daemon that lives
within systemd but runs the init script.  Note that systemd can run SysV
init scripts, but SysV is being deprecated by nearly every major distro
so there's no point in using a feature that everyone claims is going
away.

What probably annoys me most is that systemd is anything but Unix.  It's
more of MS philosophy: one big conglomeration of stuff that does
everything.  Instead of small, specialized tools chained together,
systemd gives you the kitchen sink when all you wanted was a squirt gun.

After much research I've come to the conclusion that systemd is fine for
the general-use case like desktops or web servers.  For a
purpose-specific platform it's overkill and just basically more things
to maintain.  If I had a choice I wouldn't use it all, since parallel
booting of init processes is not a concern for our system.    Our kernel
is trimmed down and we disable most typical services, including
networking and logins.  So the benefits of systemd are lost on our use
case.  We're better off with a more simplistic SysV boot process.  In
fact, I claim that any embedded system is better off rolling a custom
init, possibly based off SysV, than using systemd.

FWIW, I didn't choose Ubuntu.  It was thrust upon me.  If I had my way
I'd roll my own distro...

Along that same line of thought, I'm trying to figure out the best way
to exit Fedora and enter a new distro at home.  I just can't decide if I
want to take the effort of making my own package-based distro, use a
Buildroot-based rolling-image release method (ala embedded systems), or
use an existing disto.  I'm considering promoting my PiBox from the
RaspberryPi to my desktop, but there are many considerations before I go
that route not the least of which is how I migrate off of Evolution (I
should have stuck with Elm way-back-when...).

Any distro I choose must be SysV init.  The ugliness of systemd log
handling is not worth my effort.  Reboot times are meaningless when, at
most, I only do it once a year.

-- 
Michael J. Hammel <mjhammel at graphics-muse.org>