[Discuss] automatic daemon restarts

Jason Normand jay at lentecs.com
Tue Sep 16 09:12:08 EDT 2014


like in many things, it depends on the application.  we recently were
considering doing the same thing with the puppet agent.  The agent will
occasionally get "stuck" due to network errors and require a restart.  This
is really a bug in the application, but a fix is not expected any time
soon.  in this case simply restarting the client daemon will cause no harm
to the system.  In the case of critical application such as a databases,
restarting may not be the correct solution.

this also assuming the monitoring and restart system is intelligent enough
to not fall into a rapid fail restart loop.

On Tue, Sep 16, 2014 at 7:42 AM, Edward Ned Harvey (blu) <blu at nedharvey.com>
wrote:

> > From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> > bounces+blu=nedharvey.com at blu.org] On Behalf Of Tom Metro
> >
> > Richard Pieri wrote:
> > > Edward Ned Harvey (blu) wrote:
> > >> An active system will notice mysqld died, recognize that it's not
> > >> supposed to do that right now, and restart it.
> > >
> > > Which is a stupid way to run in production. There's a reason why the
> > > daemon died. That reason needs to be identified so that corrective
> steps
> > > can be taken. Blind restarts can obfuscate this information, can cause
> > > damage to data, and can exacerbate existing damage.
> >
> > Not to say your points are invalid, but Netflix would disagree with you.
> > They created a testing tool that intentionally kills random services on
> > their production systems just to test that automated recovery works
> > correctly.
>
> I would rather receive notification that a production service was
> *restarted* rather than *is down*
>
> Richard wants to say that's stupid.  I not only disagree, I think
> Richard's position is insulting and ignorantly one-sided.
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>



More information about the Discuss mailing list