[talk] In Contrast to BSD init, A history of modern init systems (1992-2015)

[Pete Wright]

On 09/16/15 09:56, Raul Cuza wrote:
> In light of the recent discussion on *BSD and init system, I thought
> this history of modern init systems a interesting contrast:
> http://blog.darknedgy.net/technology/2015/09/05/0/
> 
> By definition of "modern", the BSD style init is the "classical" that
> these systems are not. Maybe I don't understand the problems these
> alternatives are trying to solve sufficiently. If you can shed some
> light on it, I'd love to hear it.
> 
> What I like most about the history is that most of those attempts at
> improvements have not impacted the systems I manage (conveniently
> ignoring the OS X fleets I've been in charge of at various times). For
> me, the classical solution gets the job done.
> 

Hy Raul I agree with you for sure.  I have often thought about this
going back to when I had to support some production systems that were
using daemontools as their service monitor some time ago.

(FWIW - i think calling things like daemontools, upstart, systemd, etc.
service monitors is more descriptive about their goals than calling them
a new implementations of BSD or SysV init.)

a couple of use-cases I've seen for these process supervisors:

- developer has written a daemonized processes.  it's buggy and crashes
periodically, but we don't have resources at the moment to fix the bug
causing the daemon to crash because corporations are bad and should feel
bad.  we used daemontools to monitor that the deamon was running, and
had it automatically restart if it crashed.

- a vendor has supplied a suite of tools that are very complex to
manage, and have a complicated hierarchy of services that need to be
running before they can start themselves.  for example - my application
server needs the local oracle DB server up first, which depends on some
iSCSI volumes to get mounted which depends on a functioning IP stack
etc.  some of these process supervisors can make it easy(?) to manage
these poorly thought-out (and inevitably proprietary) software suites.


As you'll note - neither of these use-cases were about a system monitor
buying me something i couldn't accomplish with standard sysv or bsd
init.  IMHO they are more often used to bury your org's technical debt -
which i reckon is probably the worst thing you can do with tech debt.

I'm sure there are some very valid use-cases for these system monitors
that i'm not thinking of, but from my own experience i've never really
seen the benefit.

anywho those are my two bits on this.
-pete

-- 
Pete Wright
pete at nomadlogic.org
twitter => @nomadlogicLA