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][email protected].
> 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:[email protected]
> 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 [email protected].
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.
