Nick,

I would recommend using Nagios event handlers for this if you want Nagios to 
essentially take the reigns of this problem. That way you will get your alerts 
and Nagios can react by starting the service again after x number of failures.

I understand you may want to do this through Puppet for architecture reasons 
but that's just the way I'd do it per your desire.

Good luck!

-Mark

On Dec 20, 2010, at 1:57 PM, Nick Moffitt wrote:

> I'd like to know the best way to fix the refresh/restart behavior of
> Service resources without using ensure => running.
> 
> I know that this is an unpopular requirement, but I do not want puppet
> to restart dying services before my monitoring system notices.  If a
> service is fragile, I want to be woken up at 3am.  In the worst case,
> ensure => running could restart my service every ten minutes, nagios
> could check it a few seconds after, and it could die again a few seconds
> past that.  With the right harmonics a service could be effectively 99%
> downtime and ensure => running would prevent me from finding out.
> 
> I looked into writing a provider to fix this, but it appears that the
> provider.restart doesn't even get *called* by the core service type
> unless we're ensure => running or status comes back as running.  Now I
> *do* want the system to enforce the running state at the moment a
> configuration change has sent a refresh to the service, but not
> otherwise!
> 
> So how can I best do this?  Ideally I'd like for the ensure => running
> behavior to obey something like the Exec resource's "refreshonly"
> parameter.  It seems like this is up at the type level, but is there a
> simple way to monkey-patch this for now?  
> 
> -- 
> Hey, how come nobody here in the future
> has a time machine except me?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to