I don't think it's a bug that puppet sees two reasons to bounce the
service, I think it's a bug that it's only doing it when I change the
checksum to mtime. The default is md5 (I think) and it would appear
that when you define a file resource that is a directory with recurse
=> true, puppet should generate md5s on all the files in that dir on
the first run, so it can keep track of them later, regardless of
whether puppet is copying the files into that directory or not. It
seems to only work if puppet is sourcing the files in the directory.
It should work either way.
On Nov 7, 3:59 pm, "Paul Lathrop" <[EMAIL PROTECTED]> wrote:
> No, not a bug at all. Why do you think it might be?
>
> There is no reason to be concerned by the multiple notifications,
> either; Puppet is smart enough to only refresh the service once.
>
> --Paul
>
> On Fri, Nov 7, 2008 at 12:52 PM, joe <[EMAIL PROTECTED]> wrote:
>
> > This is interesting. What you describe does work, but it appears
> > there's a bug somewhere. I'm getting 2 reasons to bounce the service
> > out of the single file definition when checksum is mtime. Here is the
> > output:
>
> > # puppetd --test
> > info: Caching catalog at /var/lib/puppet/localconfig.yaml
> > notice: Starting catalog run
> > notice: //Node[removed]/dns/File[/opt/management/dns/zones]/checksum:
> > checksum changed '{mtime}Fri Nov 07 15:46:17 -0500 2008' to
> > '{mtime}Fri Nov 07 15:47:02 -0500 2008'
> > notice: //Node[removed]/dns/File[/opt/management/dns/zones/removed-
> > ext.zone]/checksum: checksum changed '{mtime}Fri Nov 07 15:46:17 -0500
> > 2008' to '{mtime}Fri Nov 07 15:47:02 -0500 2008'
> > info: //Node[removed]/dns/File[/opt/management/dns/zones]: Scheduling
> > refresh of Service[named]
> > info: //Node[removed]/dns/File[/opt/management/dns/zones]: Scheduling
> > refresh of Service[named]
> > notice: //Node[removed]/dns/Service[named]: Triggering 'refresh' from
> > 2 dependencies
> > notice: Finished catalog run in 6.72 seconds
>
> > It appears from this output that puppet should be checksumming files
> > on recurse => true regardless of the checksumming scheme. Is this a
> > bug?
>
> > On Nov 7, 3:11 pm, "Paul Lathrop" <[EMAIL PROTECTED]> wrote:
> >> Wrong. Set the checksum property to "mtime" on the directory resource.
> >> When a file in the directory changes, it will change the mtime of the
> >> directory which will trigger an event on any resources which subscribe
> >> to the directory.
>
> >> I have used this method a number of times to great success.
>
> >> --Paul
>
> >> On Thu, Nov 6, 2008 at 6:03 PM, Aj <[EMAIL PROTECTED]> wrote:
>
> >> > No, there is no way.
>
> >> > On 7/11/2008, at 1:01 PM, joe <[EMAIL PROTECTED]> wrote:
>
> >> >> I just added the require after subscribe alone didn't work.
>
> >> >> I thought that if I specified the directory with recurse => true, it
> >> >> would monitor all the files in the directory as well.
>
> >> >> Is there a way to have puppet monitor files it isn't sourcing?
>
> >> >> On Nov 6, 3:41 pm, Aj <[EMAIL PROTECTED]> wrote:
> >> >>> This notification will only fire if the managed parameters for the
> >> >>> directory are out of sync, e.g. Owner/group/modes/file type (link,
> >> >>> file).
>
> >> >>> Subscribe also implies require, FYI =)
>
> >> >>> On 7/11/2008, at 8:38 AM, joe <[EMAIL PROTECTED]> wrote:
>
> >> >>>> It's a defined file resource without a source parameter. Here is
> >> >>>> the
> >> >>>> syntax:
>
> >> >>>> file { "/opt/management/dns/zones":
> >> >>>> owner => "root",
> >> >>>> group => "root",
> >> >>>> mode => "644",
> >> >>>> ensure => directory,
> >> >>>> recurse => true }
>
> >> >>>> Then there is a service resource that subscribes to that file:
>
> >> >>>> service { "named":
> >> >>>> enable => true,
> >> >>>> ensure => running,
> >> >>>> require => File["/etc/named.conf"],
> >> >>>> require => File["/opt/dns/management/zones"],
> >> >>>> require => Package["bind"],
> >> >>>> subscribe => File["/etc/named.conf"],
> >> >>>> subscribe => File["/opt/management/dns/zones"] }
>
> >> >>>> But the service never restarts when files in that directory
> >> >>>> change. I
> >> >>>> would think it's because I'm not sourcing those files, but I'm not
> >> >>>> sure.
>
> >> >>>> On Nov 6, 12:37 pm, "Evan Hisey" <[EMAIL PROTECTED]> wrote:
> >> >>>>> On Wed, Nov 5, 2008 at 6:19 PM, joe <[EMAIL PROTECTED]> wrote:
>
> >> >>>>>> I'm having a similar issue that that wiki entry does not directly
> >> >>>>>> address.
>
> >> >>>>>> I'm trying to do a subscribe on a file definition that is a
> >> >>>>>> directory.
>
> >> >>>>>> I have ensure => directory and recurse => true.
>
> >> >>>>>> I do not use puppet to source the files (they are on nfs shared to
> >> >>>>>> all
> >> >>>>>> servers that use them).
>
> >> >>>>>> Puppet will not restart a service subscribed to this file
> >> >>>>>> definition.
> >> >>>>>> It does not seem to look at whether the files in the directory
> >> >>>>>> have
> >> >>>>>> changed.
>
> >> >>>>>> How do others make such a scenario work?
>
> >> >>>>>> Thanks
>
> >> >>>>> Is puppet actually managing the directory? Unless puppet manages
> >> >>>>> the
> >> >>>>> directory it can't know to handle a restart.
>
> >> >>>>> Evan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
