I have had a similar problem with the MySQL service. I don't want that to automatically restart when the config file changes, so I wrote a fact that checks that start time of the mysqld process compared to the last modified time of the config file and returns true or false, depending whether the config file is "newer". This fact value can then be used to either report on via puppetdb, or update the /etc/motd or whatever you want.
On Thursday, 19 March 2015 14:31:51 UTC, 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. > > Cheers > Nick > -- 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/dd281168-7696-451d-8e9f-3ca34cec6404%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
