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

[Edward Capriolo]

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

' We all have done this, but this is a very dangerous path. I worked at a
place where I was a sysadmin. I was BLAMED because my 'restart processes'
failed to properly restart 'buggy developer process x'. I always consider
this the first step on the highway to hell (aka Janitor ops). Once the
enterprise adopts the notion that 'smart developer types' are 'too busy' to
make processes that do not crash or do not fill disk with logs, all the
crap work falls on ops. Soon people sending you tar files because they 'too
busy to make installer'.

Flashbacks sorry.

In the end having something restart downed processes is smart but if
anything starts crashing repeatedly something need to be done. IE 1 random
crash a week means someone go fix it!

On Mon, Sep 21, 2015 at 4:58 PM, Pete Wright <pete at nomadlogic.org> wrote:

>
>
> 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
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20150921/c76aae15/attachment.htm>