<div dir="ltr">"<span style="font-size:12.8000001907349px"> developer has written a daemonized processes.  it's buggy and crashes</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">periodically, but we don't have resources at the moment to fix the bug</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">causing the daemon to crash because corporations are bad and should feel</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">bad.  we used daemontools to monitor that the deamon was running, and</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">had it automatically restart if it crashed."<br><br>' 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'. <br><br>Flashbacks sorry.<br><br>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!</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 21, 2015 at 4:58 PM, Pete Wright <span dir="ltr"><<a href="mailto:pete@nomadlogic.org" target="_blank">pete@nomadlogic.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 09/16/15 09:56, Raul Cuza wrote:<br>
> In light of the recent discussion on *BSD and init system, I thought<br>
> this history of modern init systems a interesting contrast:<br>
> <a href="http://blog.darknedgy.net/technology/2015/09/05/0/" rel="noreferrer" target="_blank">http://blog.darknedgy.net/technology/2015/09/05/0/</a><br>
><br>
> By definition of "modern", the BSD style init is the "classical" that<br>
> these systems are not. Maybe I don't understand the problems these<br>
> alternatives are trying to solve sufficiently. If you can shed some<br>
> light on it, I'd love to hear it.<br>
><br>
> What I like most about the history is that most of those attempts at<br>
> improvements have not impacted the systems I manage (conveniently<br>
> ignoring the OS X fleets I've been in charge of at various times). For<br>
> me, the classical solution gets the job done.<br>
><br>
<br>
Hy Raul I agree with you for sure.  I have often thought about this<br>
going back to when I had to support some production systems that were<br>
using daemontools as their service monitor some time ago.<br>
<br>
(FWIW - i think calling things like daemontools, upstart, systemd, etc.<br>
service monitors is more descriptive about their goals than calling them<br>
a new implementations of BSD or SysV init.)<br>
<br>
a couple of use-cases I've seen for these process supervisors:<br>
<br>
- developer has written a daemonized processes.  it's buggy and crashes<br>
periodically, but we don't have resources at the moment to fix the bug<br>
causing the daemon to crash because corporations are bad and should feel<br>
bad.  we used daemontools to monitor that the deamon was running, and<br>
had it automatically restart if it crashed.<br>
<br>
- a vendor has supplied a suite of tools that are very complex to<br>
manage, and have a complicated hierarchy of services that need to be<br>
running before they can start themselves.  for example - my application<br>
server needs the local oracle DB server up first, which depends on some<br>
iSCSI volumes to get mounted which depends on a functioning IP stack<br>
etc.  some of these process supervisors can make it easy(?) to manage<br>
these poorly thought-out (and inevitably proprietary) software suites.<br>
<br>
<br>
As you'll note - neither of these use-cases were about a system monitor<br>
buying me something i couldn't accomplish with standard sysv or bsd<br>
init.  IMHO they are more often used to bury your org's technical debt -<br>
which i reckon is probably the worst thing you can do with tech debt.<br>
<br>
I'm sure there are some very valid use-cases for these system monitors<br>
that i'm not thinking of, but from my own experience i've never really<br>
seen the benefit.<br>
<br>
anywho those are my two bits on this.<br>
<span class="HOEnZb"><font color="#888888">-pete<br>
<br>
--<br>
Pete Wright<br>
<a href="mailto:pete@nomadlogic.org">pete@nomadlogic.org</a><br>
twitter => @nomadlogicLA<br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@lists.nycbug.org">talk@lists.nycbug.org</a><br>
<a href="http://lists.nycbug.org/mailman/listinfo/talk" rel="noreferrer" target="_blank">http://lists.nycbug.org/mailman/listinfo/talk</a><br>
</font></span></blockquote></div><br></div>