[ale] systemd bad. Very bad.

[Solomon Peachy]

On Thu, Jun 29, 2017 at 03:06:12PM -0400, Kyle Brieden wrote:
> In the spirit of giving it a fair shake, Solomon, would you be willing to
> expound upon what you've learned about systemd that makes you appreciate
> (like?) it?

First, I should give a bit of background where I'm coming from.  I've 
been a sysadmin (unofficial and official) for about two decades.  I've 
written and maintained cross-distro init scripts that run the gamut from 
trivial thigns to stuff had to interact with distros in areas where no 
two were the same (ie the network layer).  

I've also built and maintained distros meant for severely 
resource-constrained embedded systems, having to create a whole set of 
init scripts from scratch, plus build tools to enable the system to be 
reasonably robust.  systemd would have obviated the need for all of 
this.

I've had to play some crazy games to capture logging from stdout/stderr 
when daemons blurt out crap and crash instead of logging properly.  I've 
had stuff fail to restart due to leftover detritus on the filesystem but 
that wasn't evident until the daemon had already double-forked.  I've 
had stuff fail to stop because of a stuck process or another process 
left lying around.  No more relying on pidfiles that could go stale and 
lead you to killing the wrong thing.  No more surprises due to slight 
differences in shell syntax.  And let's not even go into daemon 
interdependencies, chroot jails, private /tmp, enforcing resource 
limits, and other such fun stuff -- I could go on and on.

systemd pulls this under a single, integrated umbrella, focused on 
managing the system as a whole.  It presents a consistent interface and 
configuration and yields vast improvements in operational robustness.  
It centralizes _all_ logging, not just what the daemon sends to syslog.  
It provides bulletproof code for socket activation, double-forking 
recalcitrant daemons, chrooting, resource limitations, and much more -- 
each requiring only adding a single line to the service configuration.  
When it kills stuff, you know it will be dead.  When you restart 
something, you know everything that depends on it will also get 
restarted.  When you start something, you know that everything it 
depends on will also get started.  It provides at-a-glance status of 
individual daemons and also the system as a whole, telling you what is 
or isn't running, what was supposed to start but didn't.

And that's just from a sysadmin's perspective -- it doesn't even 
touch on the the benefits for people putting together distributions or 
full desktop users.

I could write far more on this, but that will have to do.

Anyway, back to work.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20170629/4fe78625/attachment.sig>