notice: /subject.sol1.net/virtual_mail_server/File[/etc/postfix]/checksum:
checksum changed ''{time}Thu Jan 25 16:31:08 EST 2007'' to
''{time}Thu Jan 25
16:36:39 EST 2007''
I know there''s something weird in the directory modification detection
that
causes the next run after things actually change to suffer from this
problem, but I''m getting it *every* *single* *time* I run Puppet, even
though nothing changes (and Puppet doesn''t say anything about anything
else
changing).
It''s quite irritating, because it triggers a Postfix restart every
time,
which tends to do unpleasant thing to mail handling.
Any hints on hunting the problem down, or avoiding it (if it''s a known
problem)?
- Matt
On Thu, 2007-01-25 at 16:44 +1100, Matthew Palmer wrote:> notice: /subject.sol1.net/virtual_mail_server/File[/etc/postfix]/checksum: > checksum changed ''{time}Thu Jan 25 16:31:08 EST 2007'' to ''{time}Thu Jan 25 > 16:36:39 EST 2007'' > > I know there''s something weird in the directory modification detection that > causes the next run after things actually change to suffer from this > problem, but I''m getting it *every* *single* *time* I run Puppet, even > though nothing changes (and Puppet doesn''t say anything about anything else > changing).The "{time}..." should be the ctime of the directory (you can verify with "ls -ldc /etc/postfix". What I think may be happening is that Puppet is just setting owner, group, and mode on the directory unconditionally rather than making changes only if needed. That changes the ctime, and thus changes the "checksum". Of course, I''m no Ruby hacker so I could be interpreting the code all wrong. Jeff _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Thu, Jan 25, 2007 at 12:34:36AM -0600, Jeffrey C. Ollie wrote:> On Thu, 2007-01-25 at 16:44 +1100, Matthew Palmer wrote: > > notice: /subject.sol1.net/virtual_mail_server/File[/etc/postfix]/checksum: > > checksum changed ''{time}Thu Jan 25 16:31:08 EST 2007'' to ''{time}Thu Jan 25 > > 16:36:39 EST 2007'' > > > > I know there''s something weird in the directory modification detection that > > causes the next run after things actually change to suffer from this > > problem, but I''m getting it *every* *single* *time* I run Puppet, even > > though nothing changes (and Puppet doesn''t say anything about anything else > > changing). > > The "{time}..." should be the ctime of the directory (you can verify > with "ls -ldc /etc/postfix".Yes.> What I think may be happening is that Puppet is just setting owner, group, > and mode on the directory unconditionally rather than making changes only > if needed.That''s an interesting thought. Puppet isn''t reporting that it''s making any changes like that (or any changes at all, actually), and it doesn''t do the same thing on any of the other multitude of directories I copy across. Also, running chown (the command line version, admittedly) on the directory to set the owner to what it already is doesn''t change the ctime. For all that, it''s obvious that Puppet is making *some* change, because the mtime and ctime does change with each Puppet run. I get the feeling I''m going to do be doing a lot of tracing to solve this problem. - Matt -- The hypothalamus is one of the most important parts of the brain, involved in many kinds of motivation, among other functions. The hypothalamus controls the "Four F''s": 1. fighting; 2. fleeing; 3. feeding; and 4. mating. -- Psychology professor in neuropsychology intro course
On Thu, 2007-01-25 at 18:12 +1100, Matthew Palmer wrote:> > For all that, it''s obvious that Puppet is making *some* change, because the > mtime and ctime does change with each Puppet run. I get the feeling I''m > going to do be doing a lot of tracing to solve this problem.Are you positive that Puppet is making the change? Could Postfix be responsible in some way (I don''t know, I don''t use Postfix)? Jeff _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 24, 2007, at 11:44 PM, Matthew Palmer wrote:> notice: /subject.sol1.net/virtual_mail_server/File[/etc/postfix]/ > checksum: > checksum changed ''{time}Thu Jan 25 16:31:08 EST 2007'' to ''{time}Thu > Jan 25 > 16:36:39 EST 2007'' > > I know there''s something weird in the directory modification > detection that > causes the next run after things actually change to suffer from this > problem, but I''m getting it *every* *single* *time* I run Puppet, even > though nothing changes (and Puppet doesn''t say anything about > anything else > changing). > > It''s quite irritating, because it triggers a Postfix restart every > time, > which tends to do unpleasant thing to mail handling. > > Any hints on hunting the problem down, or avoiding it (if it''s a known > problem)?What version? At least one version of Puppet had this problem; it was either in the 0.19 or 0.20 series. I''m pretty sure 0.18.x is free of it, and I''m quite confident that 0.22 is free of it (I hope). -- Basic research is what I am doing when I don''t know what I am doing. --Wernher von Braun --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Thu, Jan 25, 2007 at 10:00:40AM -0600, Luke Kanies wrote:> At least one version of Puppet had this problem; it was either in the > 0.19 or 0.20 series. I''m pretty sure 0.18.x is free of it, and I''m > quite confident that 0.22 is free of it (I hope). >For what it''s worth; I''m seeing this problem with 0.22.0 (from David Lutterkort''s RHEL4 package). That is: [user@hostname tmp]% ls -l foo bar; bar: total 0 foo: total 0 [user@hostname tmp]% cat test.pp file { ''/tmp/foo'': recurse => true, source => ''/tmp/bar'', checksum => md5 } exec { ''/bin/echo foo updated'': subscribe => File[''/tmp/foo''] , refreshonly => true} [user@hostname tmp]% touch bar/wibble [user@hostname tmp]% puppet $PWD/test.pp notice: /File[/tmp/foo/wibble]/source: Could not retrieve contents for /tmp/bar/wibble notice: /File[/tmp/foo/wibble]/ensure: created notice: //Exec[/bin/echo foo updated]: Triggering ''refresh'' from 1 dependencies [user@hostname tmp]% puppet $PWD/test.pp notice: /File[/tmp/foo]/checksum: checksum changed ''{time}Fri Jan 26 13:23:21 GMT 2007'' to ''{time}Fri Jan 26 13:24:46 GMT 2007'' notice: //Exec[/bin/echo foo updated]: Triggering ''refresh'' from 1 dependencies [user@hostname tmp]% puppet $PWD/test.pp [user@hostname tmp]% So, the exec statement gets triggered twice; once when puppet actually updates the target, and then again when it notices that ctime on the directory has changed, and so resets it on the second run. It might be useful to have an option to ignore ctime changes on directories, although I''m not sure that''s the best solution. -- Ceri Storey <cez@necrofish.org.uk> ''What I really want is "apt-get smite"'' --Rob Partington http://unix.culti.st/
On Jan 26, 2007, at 7:36 AM, Ceri Storey wrote:>> > > For what it''s worth; I''m seeing this problem with 0.22.0 (from David > Lutterkort''s RHEL4 package). That is: > > [user@hostname tmp]% ls -l foo bar; > bar: > total 0 > > foo: > total 0 > [user@hostname tmp]% cat test.pp > file { ''/tmp/foo'': recurse => true, source => ''/tmp/bar'', checksum > => md5 } > exec { ''/bin/echo foo updated'': subscribe => File[''/tmp/foo''] , > refreshonly => true} > [user@hostname tmp]% touch bar/wibble > [user@hostname tmp]% puppet $PWD/test.pp > notice: /File[/tmp/foo/wibble]/source: Could not retrieve contents > for /tmp/bar/wibble > notice: /File[/tmp/foo/wibble]/ensure: created > notice: //Exec[/bin/echo foo updated]: Triggering ''refresh'' from 1 > dependencies > [user@hostname tmp]% puppet $PWD/test.pp > notice: /File[/tmp/foo]/checksum: checksum changed ''{time}Fri Jan > 26 13:23:21 GMT 2007'' to ''{time}Fri Jan 26 13:24:46 GMT 2007'' > notice: //Exec[/bin/echo foo updated]: Triggering ''refresh'' from 1 > dependencies > [user@hostname tmp]% puppet $PWD/test.pp > [user@hostname tmp]% > > So, the exec statement gets triggered twice; once when puppet actually > updates the target, and then again when it notices that ctime on the > directory has changed, and so resets it on the second run. > > It might be useful to have an option to ignore ctime changes on > directories, although I''m not sure that''s the best solution.This is a different problem from the one Matt mentioned, and one that came up recently. What you''re seeing is that the result of the sort order is directory => file => exec. The file is changing the directory''s timestamp, which doesn''t get caught until the next run. As to ignoring ctime changes... I don''t think Puppet is ready to allow that kind of specification, but I suppose we could just not check the timestamp on directories involved in a source copy. This way you''ll only get notifications if the files change, not the directories. I''ve filed it as #461. -- Smoking is one of the leading causes of statistics. -- Fletcher Knebel --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Thu, Jan 25, 2007 at 06:43:40AM -0600, Jeffrey C. Ollie wrote:> On Thu, 2007-01-25 at 18:12 +1100, Matthew Palmer wrote: > > > > For all that, it''s obvious that Puppet is making *some* change, because the > > mtime and ctime does change with each Puppet run. I get the feeling I''m > > going to do be doing a lot of tracing to solve this problem. > > Are you positive that Puppet is making the change? Could Postfix be > responsible in some way (I don''t know, I don''t use Postfix)?You are absolutely right. Part of the postfix restart process involves rebuilding a bunch of database files, which causes the files to be updated even if the source files haven''t changed. Duh to me. Sorry about the false alarm, everyone. - Matt -- The way to a man''s heart is through his stomach, that way you don''t get your knife caught in his ribs... -- Peter da Silva
On Thu, Jan 25, 2007 at 10:00:40AM -0600, Luke Kanies wrote:> On Jan 24, 2007, at 11:44 PM, Matthew Palmer wrote: > > > notice: /subject.sol1.net/virtual_mail_server/File[/etc/postfix]/ > > checksum: > > checksum changed ''{time}Thu Jan 25 16:31:08 EST 2007'' to ''{time}Thu > > Jan 25 > > 16:36:39 EST 2007'' > > > > I know there''s something weird in the directory modification > > detection that > > causes the next run after things actually change to suffer from this > > problem, but I''m getting it *every* *single* *time* I run Puppet, even > > though nothing changes (and Puppet doesn''t say anything about > > anything else > > changing). > > > > It''s quite irritating, because it triggers a Postfix restart every > > time, > > which tends to do unpleasant thing to mail handling. > > > > Any hints on hunting the problem down, or avoiding it (if it''s a known > > problem)? > > What version? > > At least one version of Puppet had this problem; it was either in the > 0.19 or 0.20 series. I''m pretty sure 0.18.x is free of it, and I''m > quite confident that 0.22 is free of it (I hope).I''ve managed to get with the modern technology and run 0.22.0 on this site, but it was all down to user error. The sanctity of the latest version is intact. <grin> - Matt -- "Left to themselves, [marketers] would butt-tag us like polar bears to track our buying habits and bombard our phones and emails and computer screens with ads benefitting them and their clients." --- Tsu Dho Nimh, NANAE
On 27/01/07 08:57 +1100, Matthew Palmer wrote:> On Thu, Jan 25, 2007 at 06:43:40AM -0600, Jeffrey C. Ollie wrote: > > On Thu, 2007-01-25 at 18:12 +1100, Matthew Palmer wrote: > > > > > > For all that, it''s obvious that Puppet is making *some* change, because the > > > mtime and ctime does change with each Puppet run. I get the feeling I''m > > > going to do be doing a lot of tracing to solve this problem. > > > > Are you positive that Puppet is making the change? Could Postfix be > > responsible in some way (I don''t know, I don''t use Postfix)? > > You are absolutely right. Part of the postfix restart process involves > rebuilding a bunch of database files, which causes the files to be updated > even if the source files haven''t changed. Duh to me. >Uh? The default Postfix restart/reload process merely closes and opens file handles, but does not build maps. Is this some kind of broken init script or wrapper? Devdas Bhagat