Issue #2555 has been updated by Andrew Parker. Target version deleted (2.7.x)
---------------------------------------- Bug #2555: Problem when ignored files change timestamp of (recursively) copied directory https://projects.puppetlabs.com/issues/2555#change-80226 Author: Sven Mueller Status: Accepted Priority: Normal Assignee: Category: file Target version: Affected Puppet version: 0.24.8 Keywords: Branch: Opening a bug as requested. Luke Kanies wrote: On Aug 12, 2009, at 5:28 AM, Sven Mueller wrote: > > > > Hi. > > > > I'm wondering wether the following is expected behaviour (and if so, > > wether it can be disabled): > > > > I have > > /etc/puppet/files/httpd/f.q.d.n/conf.d > > > > which contains a few conf.d files per host that need to be copied to > > the > > server. The /etc/puppet/files (and all subdirectories of course) is > > managed with subversion and thus (now) contains a .svn subdirectory. > > > > Situation is that on the server, /etc/httpd/conf.d has been updated > > and > > after that, the respective conf.d directory has been added/committed > > to > > subversion. Now the situation looks like this: > > > > On the server: > > ~ # ls -la /etc/httpd/conf.d > > total 96 > > drwxr-xr-x 2 root root 4096 Aug 5 14:06 . > > drwxr-xr-x 4 root root 4096 Jul 30 15:31 .. > > -rw-r--r-- 1 root root 4090 Aug 5 11:58 risk.conf > > -rw-r--r-- 1 root root 6933 Aug 5 10:33 risk.inc > > > > On the puppet master: > > # ls -la conf.d/ > > total 24 > > drwxr-xr-x 3 puppet root 4096 Aug 10 09:26 . > > drwxr-xr-x 4 puppet root 4096 Aug 10 09:26 .. > > -rw-r--r-- 1 puppet root 4090 Aug 5 11:50 risk.conf > > -rw-r--r-- 1 puppet root 6933 Aug 5 10:22 risk.inc > > drwxr-xr-x 6 puppet root 4096 Aug 10 09:27 .svn > > > > As you can see, the .svn and . on the puppet master are newer than on > > the puppet client. > > > > File type is set up to use checksum=>md5 and ignore=>".svn" (among > > others). > > > > There is a Service["httpd"] (its a RHEL5 or CentOS5 server) subscribed > > to File["/etc/httpd/conf.d"]. Now each time puppetd is running on the > > server (we don't let it run as a service, but run it manually with > > --test), it shows something along the lines of: > > > > notice: //Node[web_node]/httpd/File[/etc/httpd/conf.d]/checksum: is > > {mtime}Wed Aug 05 14:06:12 +0200 2009, should be time (noop) > > info: //Node[web_node]/httpd/File[/etc/httpd/conf.d]: Scheduling > > refresh > > of Service[httpd] > > notice: //Node[sn_web_node]/httpd/Service[httpd]: Would have triggered > > refresh from 1 dependencies > > > > This can be avoided by touching /etc/httpd/conf.d on the server, but I > > think that: > > 1) If puppet thinks the newer mtime of the directory on the puppet > > server should cause the httpd service to be refreshed, that it > > should > > update the mtime of that directory on the server in the same run (as > > to avoid repeatedly refreshing the service). > > 2) Alternatively (and in my humble opinion this should be preferred), > > only actual changes while processing the File resource should > > trigger > > the Service resource to be refreshed. > > > > Now: Is the stuff I described above expected behaviour of puppet? If > > so: > > Can I change it somehow? If not: Is there a workaround other than > > manually "touch"ing the directory on the server? And: Is there a fix > > that corrects the behaviour to act more along the lines of the two > > alternatives listed above? Hmm, this seems like a bug that would only be encountered when files you're ignoring are causing the directory's timestamp to be modified. Normally that newer file would get copied to the client, which would update the local timestamp. Can you file this as a bug? -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
