On Fri, Mar 20, 2015 at 06:17:55AM -0700, jcbollinger wrote:
> On Thursday, March 19, 2015 at 9:31:51 AM UTC-5, Nick Howes wrote:
>
> Hi,
> I've been wondering about what to do when configuration files change on
> services that I don't want to automatically restart. It's simple enough
> to make it automatically restart by having the file notify the service,
> but for important services I thought it would be good to have a module
> that could track when a dependent file (or whatever) changes, and
> updates a marker file that can then be exposed to monitoring or facts or
> whatever. The file could notify this module resource, which would touch
> a marker file relating to a particular service. We can then see through
> facts or monitoring which nodes need service X to be restarted, and do
> that manually using orchestration tool of choice.
> Has anyone else had the same requirement and made anything similar? I'll
> probably try throwing together a module to do something like this but if
> there's anything like this already in the wild I'd be interested to see
> it.
>
> You can use an Exec resource with refreshonly => true to model behavior
> that you want only in the event that another resource is updated (by
> Puppet). For example:
>
> exec { "Flag myservice for restart":
> command => '/bin/touch /var/run/services/myservice_update',
> refreshonly => true,
> subscribe => File['/etc/myservice.conf']
> }
Same concept but I've used the exec to create an external fact, then the
information is automatically exposed via mcollective/puppet explorer/etc. The
other part is making sure that your init script (upstart/systemd config)
removes this file as part of (re)starting the service.
$service = 'mysql'
$file = '/etc/mysql/my.cnf'
$factfile = "/etc/facter/facts.d/restart_needed_${service}.txt"
exec { "restart needed: ${service}":
command => "echo restart_needed_${service}=true >${factfile}",
refreshonly => true,
subscribe => File[$file],
}
> John
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [1]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/b9428def-6cd0-484b-a8e8-4cbe4ea489f8%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users+unsubscr...@googlegroups.com
> 2.
> https://groups.google.com/d/msgid/puppet-users/b9428def-6cd0-484b-a8e8-4cbe4ea489f8%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20150320140408.GA16506%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
