Puppet users - Mar 2010 - RHEL4 / 0.25.4-1 / Failed to retrieve current state of resource: Could not retrieve file metadata for

After upgradeing my staging environment to the 0.25.4-1 version
from EPEL, I''m getting the following errors from my RHEL4-clients:

	Sat Mar 06 11:47:29 +0100 2010 //ntpd/File[/etc/ntp/keys] (err): Failed to
retrieve current state of resource:  Could not retrieve file metadata for
puppet:///modules/ntpd/keys:  at /etc/puppet/modules/ntpd/manifests/init.pp:26

	Sat Mar 06 13:11:07 +0100 2010 //puppetclient/File[/etc/puppet/puppet.conf]
(err): Failed to retrieve current state of resource:  Could not retrieve file
metadata for puppet:///modules/puppetclient/puppet.conf:  at
/etc/puppet/modules/puppetclient/manifests/init.pp:8

	Sat Mar 06 13:26:06 +0100 2010 //pam/File[/etc/pam.d/sshd] (err): Failed to
retrieve current state of resource:  Could not retrieve file metadata for
puppet:///modules/pam/sshd.RedHatEnterpriseES.4:  at
/etc/puppet/modules/pam/manifests/init.pp:13


Checking the logs on one the the RHEL4-nodes for the last few hours shows that
most runs are successfull, so I don''t think this can be a configuration
error on
my part. I see the error from all modules trying to retrieve file resources, 
not just the ntpd-listed in the log below.

	Mar  6 10:16:20 rhel4node1 puppetd[8202]: Value of
''preferred_serialization_format'' (pson) is invalid for report,
using default (marshal)
	Mar  6 10:16:20 rhel4node1 puppetd[8202]: Finished catalog run in 11.15 seconds
	Mar  6 10:46:42 rhel4node1 puppetd[8202]: Value of
''preferred_serialization_format'' (pson) is invalid for report,
using default (marshal)
	Mar  6 10:46:42 rhel4node1 puppetd[8202]: Finished catalog run in 11.08 seconds
	Mar  6 11:17:08 rhel4node1 puppetd[8202]: (//ntpd/File[/etc/ntp/keys]) Failed
to retrieve current state of resource:  Could not retrieve file metadata for
puppet:///modules/ntpd/keys:  at /etc/puppet/modules/ntpd/manifests/init.pp:26
	Mar  6 11:17:08 rhel4node1 puppetd[8202]: Value of
''preferred_serialization_format'' (pson) is invalid for report,
using default (marshal)
	Mar  6 11:17:09 rhel4node1 puppetd[8202]: Finished catalog run in 12.90 seconds
	Mar  6 11:47:29 rhel4node1 puppetd[8202]: (//ntpd/File[/etc/ntp/keys]) Failed
to retrieve current state of resource:  Could not retrieve file metadata for
puppet:///modules/ntpd/keys:  at /etc/puppet/modules/ntpd/manifests/init.pp:26
	Mar  6 11:47:30 rhel4node1 puppetd[8202]: Value of
''preferred_serialization_format'' (pson) is invalid for report,
using default (marshal)
	Mar  6 11:47:30 rhel4node1 puppetd[8202]: Finished catalog run in 8.72 seconds
	Mar  6 12:17:52 rhel4node1 puppetd[8202]: Value of
''preferred_serialization_format'' (pson) is invalid for report,
using default (marshal)
	Mar  6 12:17:52 rhel4node1 puppetd[8202]: Finished catalog run in 10.37 seconds
	Mar  6 12:48:15 rhel4node1 puppetd[8202]: Value of
''preferred_serialization_format'' (pson) is invalid for report,
using default (marshal)
	Mar  6 12:48:16 rhel4node1 puppetd[8202]: Finished catalog run in 10.95 seconds
	Mar  6 13:18:35 rhel4node1 puppetd[8202]: Value of
''preferred_serialization_format'' (pson) is invalid for report,
using default (marshal)
	Mar  6 13:18:35 rhel4node1 puppetd[8202]: Finished catalog run in 8.90 seconds
	Mar  6 13:48:49 rhel4node1 puppetd[8202]: (//ntpd/File[/etc/ntp/keys]) Failed
to retrieve current state of resource:  Could not retrieve file metadata for
puppet:///modules/ntpd/keys:  at /etc/puppet/modules/ntpd/manifests/init.pp:26
	Mar  6 13:48:59 rhel4node1 puppetd[8202]: Value of
''preferred_serialization_format'' (pson) is invalid for report,
using default (marshal)
	Mar  6 13:48:59 rhel4node1 puppetd[8202]: Finished catalog run in 12.44 seconds

As far as I can see, all RHEL5 puppets are running fine.


  -jf

-- 
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
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mar 6, 2:18 pm, Jan-Frode Myklebust <janfr...@tanso.net> wrote:
> As far as I can see, all RHEL5 puppets are running fine.
Oops, no, I''ve gotten this once now from a RHEL5 host too. The only 32-
bit RHEL5-host I have in this environment.

My staging environment has 20 hosts:

3x 32-bit RHEL4
1x 32-bit RHEL5
16x 64bit RHEL5

and the error has only come from the 32-bit hosts.

I''m also wondering if this could simply be caused by an overloaded
puppetmaster, as it''s only running a single puppetmaster-process... ?
But that doesn''t explain why I''m not seeing this problem on
the 64-bit
machines...


  -jf

-- 
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
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 2010-03-06, janfrode <janfrode@tanso.net>
wrote:
>
> I''m also wondering if this could simply be caused by an overloaded
> puppetmaster, as it''s only running a single
puppetmaster-process... ?
> But that doesn''t explain why I''m not seeing this problem
on the 64-bit
> machines...
>
.. and after setting up apache to loadbalance over 4 mongrels, the
problem went away. Hmm, seems a bit scary that 20 nodes was enough
to cause problems for a single puppetmaster... but the puppetmaster 
here is a virtual machine, so it might not be the fastest machine
there is...


  -jf

-- 
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
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

webrick was never designed for large scale (read more than a few machines)
setup, so its not surprising that it fails for 20 nodes that query the
puppetmaster at a specific time.

more than that, the puppetmaster process (even if running under
mongrel/passenger etc) probably cant handle much more then 20 connections at
the same second regardless.

cheers,
Ohad

On Mon, Mar 8, 2010 at 5:09 AM, Jan-Frode Myklebust
<janfrode@tanso.net>wrote:
> On 2010-03-06, janfrode <janfrode@tanso.net> wrote:
> >
> > I''m also wondering if this could simply be caused by an
overloaded
> > puppetmaster, as it''s only running a single
puppetmaster-process... ?
> > But that doesn''t explain why I''m not seeing this
problem on the 64-bit
> > machines...
> >
>
> .. and after setting up apache to loadbalance over 4 mongrels, the
> problem went away. Hmm, seems a bit scary that 20 nodes was enough
> to cause problems for a single puppetmaster... but the puppetmaster
> here is a virtual machine, so it might not be the fastest machine
> there is...
>
>
>  -jf
>
> --
> 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
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
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
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.