Tracking services that need to be restarted

49 views
Skip to first unread message

Nick Howes

unread,
Mar 19, 2015, 10:31:51 AM3/19/15
to puppet...@googlegroups.com
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

jamese

unread,
Mar 20, 2015, 4:13:37 AM3/20/15
to puppet...@googlegroups.com
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.

jcbollinger

unread,
Mar 20, 2015, 9:17:55 AM3/20/15
to puppet...@googlegroups.com
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']
}


John

Christopher Wood

unread,
Mar 20, 2015, 10:04:25 AM3/20/15
to puppet...@googlegroups.com
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...@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...@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

Nick Howes

unread,
Mar 24, 2015, 9:32:43 AM3/24/15
to puppet...@googlegroups.com, christop...@pobox.com

On Friday, 20 March 2015 14:04:25 UTC, Christopher Wood wrote:
On Fri, Mar 20, 2015 at 06:17:55AM -0700, jcbollinger wrote:

>    exec  {  "Flag myservice for restart":
>      command =>  '/bin/touch /var/run/services/myservice_update',
>      refreshonly =>  true,
>      subscribe =>  File['/etc/myservice.conf']
>    }

exec { "restart needed: ${service}":
  command     => "echo restart_needed_${service}=true >${factfile}",
  refreshonly => true,
  subscribe   => File[$file],
}


Thanks all - sounds like generating a marker file would be pretty straightforward, and I like the idea of comparing the file's timestamp against the service start time. 
Reply all
Reply to author
Forward
0 new messages