Puppet users - Oct 2012 - err: Could not retrieve catalog from remote server: Error 400 on SERVER: allocator undefined for Proc

My puppet setup break just a few hours with this message.

I didn''t upgrade anything, didn''t really changed my module and
it just broke. The node what where working suddenly stop working.

I''m using the official Puppet 3.0 on Scientific Linux (aka Redhat) 6.3

Can some one explain me this magic ?

-- 
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.

Could you check the server logs and run the master with --verbose
--debug --trace?

The information I''m looking for is a backtrace to the file and ljne
number that raised that exception.

Thanks,
-Jeff

On Oct 18, 2012, at 5:26 AM, Fabrice Bacchella <fbacchella@spamcop.net>
wrote:
> My puppet setup break just a few hours with this message.
>
> I didn''t upgrade anything, didn''t really changed my
module and it just broke. The node what where working suddenly stop working.
>
> I''m using the official Puppet 3.0 on Scientific Linux (aka Redhat)
6.3
>
> Can some one explain me this magic ?
>
> --
> 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.
>
-- 
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.

Here it is :
[2012-10-22 17:18:50] puppet-master[25373]: allocator undefined for Proc
[2012-10-22 17:18:50] puppet-master[25373]: /usr/lib/ruby/1.8/yaml.rb:133:in
`transfer''
[2012-10-22 17:18:50] puppet-master[25373]: /usr/lib/ruby/1.8/yaml.rb:133:in
`node_import''
[2012-10-22 17:18:50] puppet-master[25373]: /usr/lib/ruby/1.8/yaml.rb:133:in
`load''
[2012-10-22 17:18:50] puppet-master[25373]: /usr/lib/ruby/1.8/yaml.rb:133:in
`load''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/util/rails/reference_serializer.rb:6:in
`unserialize_value''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:64:in
`find_all_params_from_host''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:63:in `each''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:63:in
`find_all_params_from_host''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:232:in
`find_resources_parameters''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:119:in
`find_resources_parameters_tags''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:101:in
`merge_resources''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:23:in
`debug_benchmark''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/core_ext/benchmark.rb:8:in
`realtime''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:23:in
`debug_benchmark''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:100:in
`merge_resources''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/active_record.rb:25:in
`save''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/core_ext/benchmark.rb:8:in
`realtime''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/active_record.rb:24:in
`save''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/store_configs.rb:24:in
`save''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:195:in
`find''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:108:in
`do_find''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in `send''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in
`process''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick/rest.rb:24:in
`service''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:33:in
`listen''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/server.rb:173:in `call''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:30:in
`listen''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in
`initialize''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in `new''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in
`listen''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:26:in
`synchronize''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:26:in
`listen''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:92:in `listen''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:104:in `start''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:136:in `start''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:199:in `main''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:148:in
`run_command''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:438:in `plugin_hook''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:500:in `exit_on_fail''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
[2012-10-22 17:18:50] puppet-master[25373]:
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:87:in `execute''
[2012-10-22 17:18:50] puppet-master[25373]: /usr/bin/puppet:4



Le 18 oct. 2012 à 17:26, Jeff McCune a écrit :
> Could you check the server logs and run the master with --verbose
> --debug --trace?
> 
> The information I''m looking for is a backtrace to the file and
ljne
> number that raised that exception.
> 
> Thanks,
> -Jeff
> 
> On Oct 18, 2012, at 5:26 AM, Fabrice Bacchella
<fbacchella@spamcop.net> wrote:
> 
>> My puppet setup break just a few hours with this message.
>> 
>> I didn''t upgrade anything, didn''t really changed my
module and it just broke. The node what where working suddenly stop working.
>> 
>> I''m using the official Puppet 3.0 on Scientific Linux (aka
Redhat) 6.3
>> 
>> Can some one explain me this magic ?
>> 
>> --
>> 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.
>> 
> 
> -- 
> 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.
> 
-- 
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.

Thanks, I didn''t get a chance to dive into this today, but
I''ll try my best
to investigate the problem soon.  If it''s Thursday and I
haven''t replied
please ping me again.

Am I correct in my understanding that this is only affecting one node?

Could you also paste the output of facter --puppet --yaml on the affected
node?

Thanks,
-Jeff

-- 
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.

Are you using stored configs?  Could you also paste your puppet.conf with
passwords redacted?

It looks like the YAML library itself is raising the exception.  Could you
apply this small patch to one of your puppet masters, then email me the
/tmp/for_jeff.json file?  This will help me understand what value might be
causing the exception in the YAML library.

Also, a viable work-around might be to switch from stored configs to
PuppetDB.

You should be able to apply this patch using:

cd /usr/lib/ruby/site_ruby/1.8
patch -p2 < /tmp/0001-WIP-Instrument-store_configs-serialization-issue.patch

Then you''d need to restart your puppet master and look for
/tmp/for_jeff.json file to be created.

Hope this helps,
-Jeff

On Mon, Oct 22, 2012 at 8:23 AM, Fabrice Bacchella
<fbacchella@spamcop.net>wrote:
> Here it is :
> [2012-10-22 17:18:50] puppet-master[25373]: allocator undefined for Proc
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/yaml.rb:133:in `transfer''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/yaml.rb:133:in `node_import''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/yaml.rb:133:in `load''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/yaml.rb:133:in `load''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/util/rails/reference_serializer.rb:6:in
> `unserialize_value''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:64:in
> `find_all_params_from_host''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:63:in
`each''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:63:in
> `find_all_params_from_host''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:232:in
> `find_resources_parameters''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:119:in
> `find_resources_parameters_tags''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:101:in
`merge_resources''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:23:in
> `debug_benchmark''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in
`railsmark''
> [2012-10-22 17:18:50] puppet-master[25373]:
>
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/core_ext/benchmark.rb:8:in
> `realtime''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in
`railsmark''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:23:in
> `debug_benchmark''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:100:in
`merge_resources''
> [2012-10-22 17:18:50] puppet-master[25373]:
>
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/active_record.rb:25:in
> `save''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in
`railsmark''
> [2012-10-22 17:18:50] puppet-master[25373]:
>
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/core_ext/benchmark.rb:8:in
> `realtime''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in
`railsmark''
> [2012-10-22 17:18:50] puppet-master[25373]:
>
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/active_record.rb:24:in
> `save''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/store_configs.rb:24:in
`save''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:195:in
`find''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:108:in
`do_find''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in
`send''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in
`process''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick/rest.rb:24:in
> `service''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:33:in
`listen''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/server.rb:173:in `call''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/server.rb:162:in `start''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/server.rb:95:in `start''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/server.rb:92:in `each''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/server.rb:92:in `start''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/server.rb:23:in `start''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/1.8/webrick/server.rb:82:in `start''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:30:in
`listen''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in
> `initialize''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in
`new''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in
`listen''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:26:in
> `synchronize''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:26:in
`listen''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:92:in
`listen''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:104:in
`start''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:136:in `start''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:199:in
`main''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:148:in
> `run_command''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:438:in
`plugin_hook''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:500:in `exit_on_fail''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
> [2012-10-22 17:18:50] puppet-master[25373]:
> /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:87:in
`execute''
> [2012-10-22 17:18:50] puppet-master[25373]: /usr/bin/puppet:4
>
>
>
> Le 18 oct. 2012 à 17:26, Jeff McCune a écrit :
>
> > Could you check the server logs and run the master with --verbose
> > --debug --trace?
> >
> > The information I''m looking for is a backtrace to the file
and ljne
> > number that raised that exception.
> >
> > Thanks,
> > -Jeff
> >
> > On Oct 18, 2012, at 5:26 AM, Fabrice Bacchella
<fbacchella@spamcop.net>
> wrote:
> >
> >> My puppet setup break just a few hours with this message.
> >>
> >> I didn''t upgrade anything, didn''t really changed
my module and it just
> broke. The node what where working suddenly stop working.
> >>
> >> I''m using the official Puppet 3.0 on Scientific Linux
(aka Redhat) 6.3
> >>
> >> Can some one explain me this magic ?
> >>
> >> --
> >> 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.
> >>
> >
> > --
> > 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.
> >
>
> --
> 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.
>
>
-- 
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.

Le 24 oct. 2012 à 17:49, Jeff McCune <jeff@puppetlabs.com> a écrit :
> Are you using stored configs?  Could you also paste your puppet.conf with
passwords redacted?
Yes I''m using stored config.
> 
> It looks like the YAML library itself is raising the exception.  Could you
apply this small patch to one of your puppet masters, then email me the
/tmp/for_jeff.json file?  This will help me understand what value might be
causing the exception in the YAML library.
> 
> Also, a viable work-around might be to switch from stored configs to
PuppetDB.
No it''s not. We''re using mysql for our database and have no
competences in postgress, so installing PuppetDB needs time, reflexion and
testing. It might be an intersting solution, but certainly not a work-around for
a bug.
> 
> You should be able to apply this patch using:
> 
> cd /usr/lib/ruby/site_ruby/1.8
> patch -p2 <
/tmp/0001-WIP-Instrument-store_configs-serialization-issue.patch
> 
> Then you''d need to restart your puppet master and look for
/tmp/for_jeff.json file to be created.
This patch does something magic. A broken node (with allocator undefined for
Proc) is working when I apply your patch to the puppet master and restart it. I
can then remove it and the node will keep working.

All of this with up to date puppet in both node and master.

Anyway, I''ll send you the requested files in a private mail.


-- 
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 Thu, Oct 25, 2012 at 4:42 AM, Fabrice Bacchella
<fbacchella@spamcop.net>wrote:
> This patch does something magic. A broken node (with allocator undefined
> for Proc) is working when I apply your patch to the puppet master and
> restart it. I can then remove it and the node will keep working.
>
Did you restart the puppet master after removing the patch?  I expect the
error to show back up once the patch is backed out and the master process
is restarted.

The "magic" is that I''m catching all exceptions and
discarding them, so the
error isn''t being raised up.  This is simply masking the problem
through,
the problem is still present so please don''t apply this patch to your
production systems or anything.

-Jeff

-- 
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.

Le 25 oct. 2012 à 18:40, Jeff McCune <jeff@puppetlabs.com> a écrit :
> On Thu, Oct 25, 2012 at 4:42 AM, Fabrice Bacchella
<fbacchella@spamcop.net> wrote:
> This patch does something magic. A broken node (with allocator undefined
for Proc) is working when I apply your patch to the puppet master and restart
it. I can then remove it and the node will keep working.
> 
> Did you restart the puppet master after removing the patch?  I expect the
error to show back up once the patch is backed out and the master process is
restarted.
> 
Yes, I restarted the puppet master each and many times. I think it gets the
configuration clean, or something like that, because broken nodes are now
working well, I just checked.
> 
> The "magic" is that I''m catching all exceptions and
discarding them, so the error isn''t being raised up.  This is simply
masking the problem through, the problem is still present so please
don''t apply this patch to your production systems or anything.
> -Jeff 
> 
> -- 
> 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.
-- 
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 Thu, Oct 25, 2012 at 11:26 AM, Fabrice Bacchella
<fbacchella@spamcop.net>wrote:
>
> Le 25 oct. 2012 à 18:40, Jeff McCune <jeff@puppetlabs.com> a écrit :
>
> On Thu, Oct 25, 2012 at 4:42 AM, Fabrice Bacchella
<fbacchella@spamcop.net
> > wrote:
>
>> This patch does something magic. A broken node (with allocator
undefined
>> for Proc) is working when I apply your patch to the puppet master and
>> restart it. I can then remove it and the node will keep working.
>>
>
> Did you restart the puppet master after removing the patch?  I expect the
> error to show back up once the patch is backed out and the master process
> is restarted.
>
>
> Yes, I restarted the puppet master each and many times. I think it gets
> the configuration clean, or something like that, because broken nodes are
> now working well, I just checked.
>
>
Weird.  Must be a heisenbug.  ;)  Resolved as soon as we started studying
it...

If you run into it again, please let me know.  I''ll still try and
reproduce
the issue with the JSON file you emailed me.

-Jeff

-- 
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.

I have run into this error on a few nodes. The only workaround I''ve
found
so far is to delete the host out of the MySQL table. Is there anything I 
can do to debug?

Running CentOS 6.3 and Puppet 3.0.1 on master. Broken nodes are mostly 
running 3.0.0 and 3.0.1, but a mixture of CentOS 5.8 and 6.3. All 64 bit.

On Thursday, 25 October 2012 19:47:02 UTC+1, Jeff McCune
wrote:
>
> On Thu, Oct 25, 2012 at 11:26 AM, Fabrice Bacchella
<fbacc...@spamcop.net<javascript:>
> > wrote:
>
>>
>> Le 25 oct. 2012 à 18:40, Jeff McCune <je...@puppetlabs.com
<javascript:>>
>> a écrit :
>>
>> On Thu, Oct 25, 2012 at 4:42 AM, Fabrice Bacchella
<fbacc...@spamcop.net<javascript:>
>> > wrote:
>>
>>> This patch does something magic. A broken node (with allocator
undefined
>>> for Proc) is working when I apply your patch to the puppet master
and
>>> restart it. I can then remove it and the node will keep working.
>>>
>>
>> Did you restart the puppet master after removing the patch?  I expect
the
>> error to show back up once the patch is backed out and the master
process
>> is restarted.
>>
>>
>> Yes, I restarted the puppet master each and many times. I think it gets
>> the configuration clean, or something like that, because broken nodes
are
>> now working well, I just checked.
>>
>>
> Weird.  Must be a heisenbug.  ;)  Resolved as soon as we started studying 
> it...
>
> If you run into it again, please let me know.  I''ll still try and 
> reproduce the issue with the JSON file you emailed me.
>
> -Jeff
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/K5CVrru5KAkJ.
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 Tuesday, November 27, 2012 at 6:25 AM, Lee Boynton
wrote:
> I have run into this error on a few nodes. The only workaround
I''ve found so far is to delete the host out of the MySQL table. Is
there anything I can do to debug?
>  
Which MySQL table are you speaking of?  Could you you paste the command
you''re using to work around the problem?
> Running CentOS 6.3 and Puppet 3.0.1 on master. Broken nodes are mostly
running 3.0.0 and 3.0.1, but a mixture of CentOS 5.8 and 6.3. All 64 bit.
>  
> On Thursday, 25 October 2012 19:47:02 UTC+1, Jeff McCune wrote:
> > On Thu, Oct 25, 2012 at 11:26 AM, Fabrice Bacchella
<fbacc...@spamcop.net> wrote:
> > >  
> > > Le 25 oct. 2012 à 18:40, Jeff McCune <je...@puppetlabs.com>
a écrit :
> > >  
> > > > On Thu, Oct 25, 2012 at 4:42 AM, Fabrice Bacchella
<fbacc...@spamcop.net> wrote:
> > > > > This patch does something magic. A broken node (with
allocator undefined for Proc) is working when I apply your patch to the puppet
master and restart it. I can then remove it and the node will keep working.
> > > >  
> > > > Did you restart the puppet master after removing the patch? 
I expect the error to show back up once the patch is backed out and the master
process is restarted.
> > > >  
> > >  
> > > Yes, I restarted the puppet master each and many times. I think
it gets the configuration clean, or something like that, because broken nodes
are now working well, I just checked.
> > >  
> >  
> > Weird.  Must be a heisenbug.  ;)  Resolved as soon as we started
studying it...
> >  
> > If you run into it again, please let me know.  I''ll still try
and reproduce the issue with the JSON file you emailed me.
> >  
> > -Jeff  
>  
> --  
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/K5CVrru5KAkJ.
> 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.
-- 
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.

delete from hosts where name = ''the.node.name'';


On 27 November 2012 16:33, Jeff McCune <jeff@puppetlabs.com> wrote:
> On Tuesday, November 27, 2012 at 6:25 AM, Lee Boynton wrote:
>
> I have run into this error on a few nodes. The only workaround
I''ve found
> so far is to delete the host out of the MySQL table. Is there anything I
> can do to debug?
>
> Which MySQL table are you speaking of?  Could you you paste the command
> you''re using to work around the problem?
>
> Running CentOS 6.3 and Puppet 3.0.1 on master. Broken nodes are mostly
> running 3.0.0 and 3.0.1, but a mixture of CentOS 5.8 and 6.3. All 64 bit.
>
> On Thursday, 25 October 2012 19:47:02 UTC+1, Jeff McCune wrote:
>
> On Thu, Oct 25, 2012 at 11:26 AM, Fabrice Bacchella
<fbacc...@spamcop.net>wrote:
>
>
> Le 25 oct. 2012 à 18:40, Jeff McCune <je...@puppetlabs.com> a écrit :
>
> On Thu, Oct 25, 2012 at 4:42 AM, Fabrice Bacchella
<fbacc...@spamcop.net>wrote:
>
> This patch does something magic. A broken node (with allocator undefined
> for Proc) is working when I apply your patch to the puppet master and
> restart it. I can then remove it and the node will keep working.
>
>
> Did you restart the puppet master after removing the patch?  I expect the
> error to show back up once the patch is backed out and the master process
> is restarted.
>
>
> Yes, I restarted the puppet master each and many times. I think it gets
> the configuration clean, or something like that, because broken nodes are
> now working well, I just checked.
>
>
> Weird.  Must be a heisenbug.  ;)  Resolved as soon as we started studying
> it...
>
> If you run into it again, please let me know.  I''ll still try and
> reproduce the issue with the JSON file you emailed me.
>
> -Jeff
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/K5CVrru5KAkJ.
> 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.
>
>
>  --
> 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.
>
-- 
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 Tue, Nov 27, 2012 at 8:39 AM, Lee Boynton <lee@lboynton.com>
wrote:
> delete from hosts where name = ''the.node.name'';
OK, so this is the hosts table, but what database?  Is this the Puppet
dashboard, Stored Configs, or something else?

--Jeff

-- 
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.

This is in the database named puppet. So, I assume that is populated by the
storeconfig option?


On 27 November 2012 16:54, Jeff McCune <jeff@puppetlabs.com> wrote:
> On Tue, Nov 27, 2012 at 8:39 AM, Lee Boynton <lee@lboynton.com>
wrote:
> > delete from hosts where name = ''the.node.name'';
>
> OK, so this is the hosts table, but what database?  Is this the Puppet
> dashboard, Stored Configs, or something else?
>
> --Jeff
>
> --
> 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.
>
>
-- 
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.

Sorry, just looked in the puppet.conf file. It is indeed the storeconfigs
option. I guess I should just go ahead and use PuppetDB.


On 27 November 2012 16:59, Lee Boynton <lee@lboynton.com> wrote:
> This is in the database named puppet. So, I assume that is populated by
> the storeconfig option?
>
>
>
> On 27 November 2012 16:54, Jeff McCune <jeff@puppetlabs.com> wrote:
>
>> On Tue, Nov 27, 2012 at 8:39 AM, Lee Boynton <lee@lboynton.com>
wrote:
>> > delete from hosts where name = ''the.node.name'';
>>
>> OK, so this is the hosts table, but what database?  Is this the Puppet
>> dashboard, Stored Configs, or something else?
>>
>> --Jeff
>>
>> --
>> 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.
>>
>>
>
-- 
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 Tue, Nov 27, 2012 at 9:06 AM, Lee Boynton <lee@lboynton.com>
wrote:
> Sorry, just looked in the puppet.conf file. It is indeed the storeconfigs
> option. I guess I should just go ahead and use PuppetDB.
PuppetDB could be a viable work around, but this is the second time
I''ve heard of someone running into this error with Storedconfigs.  We
do still support the storedconfigs feature in Puppet 3.0, so these
issues concern me.

Fabrice mentioned that restarting the puppet master helped with this
issue.  Could you please bounce the puppet master and see if that
helps resolve this issue?

Could you also enable the --verbose --debug and --trace options on
your Puppet master and paste any stack traces that show up in your
logs or on the console.  This will help me diagnose this issue
further.

Thanks,
-Jeff

-- 
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.

I ran "puppet master --verbose --debug --trace --no-daemonize --logdest
console" and I get the same as Fabrice:

Error: allocator undefined for Proc
/usr/lib/ruby/1.8/yaml.rb:133:in `transfer''
/usr/lib/ruby/1.8/yaml.rb:133:in `node_import''
/usr/lib/ruby/1.8/yaml.rb:133:in `load''
/usr/lib/ruby/1.8/yaml.rb:133:in `load''
/usr/lib/ruby/site_ruby/1.8/puppet/util/rails/reference_serializer.rb:6:in
`unserialize_value''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:64:in
`find_all_params_from_host''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:63:in `each''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:63:in
`find_all_params_from_host''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:232:in
`find_resources_parameters''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:119:in
`find_resources_parameters_tags''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:101:in
`merge_resources''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:23:in
`debug_benchmark''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark''
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/core_ext/benchmark.rb:8:in
`realtime''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:23:in
`debug_benchmark''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:100:in
`merge_resources''
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/active_record.rb:25:in
`save''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark''
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/core_ext/benchmark.rb:8:in
`realtime''
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark''
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/active_record.rb:24:in
`save''
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/store_configs.rb:24:in
`save''
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:195:in
`find''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:108:in
`do_find''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in `send''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in
`process''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick/rest.rb:24:in
`service''
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service''
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:33:in
`listen''
/usr/lib/ruby/1.8/webrick/server.rb:173:in `call''
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread''
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start''
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread''
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start''
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each''
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start''
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start''
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:30:in
`listen''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in
`initialize''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in `new''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in
`listen''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:26:in
`synchronize''
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:26:in
`listen''
/usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:92:in `listen''
/usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:104:in `start''
/usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:136:in `start''
/usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:199:in `main''
/usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:148:in
`run_command''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:438:in `plugin_hook''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:500:in `exit_on_fail''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:87:in `execute''
/usr/bin/puppet:4

Tried a complete reboot of the puppet master and this does not fix the
problem.


On 27 November 2012 18:44, Jeff McCune <jeff@puppetlabs.com> wrote:
> On Tue, Nov 27, 2012 at 9:06 AM, Lee Boynton <lee@lboynton.com>
wrote:
> > Sorry, just looked in the puppet.conf file. It is indeed the
storeconfigs
> > option. I guess I should just go ahead and use PuppetDB.
>
> PuppetDB could be a viable work around, but this is the second time
> I''ve heard of someone running into this error with Storedconfigs. 
We
> do still support the storedconfigs feature in Puppet 3.0, so these
> issues concern me.
>
> Fabrice mentioned that restarting the puppet master helped with this
> issue.  Could you please bounce the puppet master and see if that
> helps resolve this issue?
>
> Could you also enable the --verbose --debug and --trace options on
> your Puppet master and paste any stack traces that show up in your
> logs or on the console.  This will help me diagnose this issue
> further.
>
> Thanks,
> -Jeff
>
> --
> 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.
>
>
-- 
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.

I am also seeing this bug on one of my nodes (worryingly, the puppet master 
itself!) The relevant output of puppet agent -t --debug --trace --verbose 
matches what Fabrice and Lee have also reported:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
allocator undefined for Proc
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:65:in
`deserialize''
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:121:in `find''
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:191:in
`find''
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:243:in 
`retrieve_new_catalog''
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:348:in `thinmark''
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime''
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:347:in `thinmark''
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:242:in 
`retrieve_new_catalog''
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:67:in
`retrieve_catalog''
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:107:in 
`prepare_and_retrieve_catalog''
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:159:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:20:in `lock''
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run''
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize''
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:119:in `with_client''
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:42:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:84:in `run_in_fork''
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:41:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:175:in `call''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:175:in
`controlled_run''
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:339:in
`onetime''
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:312:in
`run_command''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:438:in `plugin_hook''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:500:in `exit_on_fail''
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run''
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:87:in `execute''
/usr/bin/puppet:4
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

I am also using a MySQL DB as my storeconfig.


On Tuesday, November 27, 2012 1:45:15 PM UTC-5, Jeff McCune
wrote:
>
> On Tue, Nov 27, 2012 at 9:06 AM, Lee Boynton
<l...@lboynton.com<javascript:>>
> wrote: 
> > Sorry, just looked in the puppet.conf file. It is indeed the 
> storeconfigs 
> > option. I guess I should just go ahead and use PuppetDB. 
>
> PuppetDB could be a viable work around, but this is the second time 
> I''ve heard of someone running into this error with Storedconfigs. 
We
> do still support the storedconfigs feature in Puppet 3.0, so these 
> issues concern me. 
>
> Fabrice mentioned that restarting the puppet master helped with this 
> issue.  Could you please bounce the puppet master and see if that 
> helps resolve this issue? 
>
> Could you also enable the --verbose --debug and --trace options on 
> your Puppet master and paste any stack traces that show up in your 
> logs or on the console.  This will help me diagnose this issue 
> further. 
>
> Thanks, 
> -Jeff 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/_g4_Ggww240J.
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 Wed, Nov 28, 2012 at 10:55 AM, John Lamb <lambjw@wfu.edu>
wrote:
> I am also seeing this bug on one of my nodes (worryingly, the puppet master
> itself!) The relevant output of puppet agent -t --debug --trace --verbose
> matches what Fabrice and Lee have also reported:
OK, there''s definitely a bug somewhere...

I''m going to work on reproducing this issue tomorrow.  Before then,
could anyone affected by this "allocator undefined for Proc" error
please let me know what exact versions of the operating system, Ruby,
and Puppet they''re running?

If possible, if you could just privately email me the output of facter
from an affected Puppet master that would be greatly helpful in
reproducing this issue.

Finally, could you please send me (privately) a copy and paste of all
exported resources in your manifests?  You can probably find them
easiest with a recursive grep against "@@".  This will help me
populate the storedconfigs database so I can reproduce this issue.

Thanks,
-Jeff

-- 
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.

Le 27 nov. 2012 à 19:44, Jeff McCune <jeff@puppetlabs.com> a écrit :

> Fabrice mentioned that restarting the puppet master helped with this
> issue.  Could you please bounce the puppet master and see if that
> helps resolve this issue?
Restarting the puppet master was not enough. I need to restart it with your
patch once. And then the node is healed, forever.

-- 
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.

OS: Red Hat Enterprise Linux Server release 6.3 (Santiago)
Ruby: ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
Puppet: puppet-3.0.1-1.el6.noarch

I can get the facter output to you later today.

For what it''s worth, I ran into this problem as I was developing a
class
within an already-existing service. I referenced one or several resources 
that didn''t actually exist (via the require metaparameter - I tried to 
require Group[''git''],) and after fixing this issue I was no
longer able to
get my puppet agent runs to work, even after commenting out all the changes 
I had made.

I was able to "fix" this by trying "puppet node clean
broken.node.name",
which failed, then I tested puppet node clean against a working node, which 
also failed, then on a whim I tried it against the broken node once more, 
at which point it worked. Since then puppet has worked as usual.

The error I got from puppet node clean is:
Error: uninitialized constant ActiveRecord::Base
Error: Try ''puppet help node clean'' for usage

Interestingly, this morning our puppet deprecation report told us: "11 
ActiveRecord-based storeconfigs and inventory are deprecated." We normally 
don''t have any deprecated storeconfigs. We have a total of 25 machines.
I
don''t know if this is related to the issue at large.

On Wednesday, November 28, 2012 8:09:38 PM UTC-5, Jeff McCune
wrote:
>
> On Wed, Nov 28, 2012 at 10:55 AM, John Lamb <lam...@wfu.edu
<javascript:>>
> wrote: 
> > I am also seeing this bug on one of my nodes (worryingly, the puppet 
> master 
> > itself!) The relevant output of puppet agent -t --debug --trace 
> --verbose 
> > matches what Fabrice and Lee have also reported: 
>
> OK, there''s definitely a bug somewhere... 
>
> I''m going to work on reproducing this issue tomorrow.  Before
then,
> could anyone affected by this "allocator undefined for Proc"
error
> please let me know what exact versions of the operating system, Ruby, 
> and Puppet they''re running? 
>
> If possible, if you could just privately email me the output of facter 
> from an affected Puppet master that would be greatly helpful in 
> reproducing this issue. 
>
> Finally, could you please send me (privately) a copy and paste of all 
> exported resources in your manifests?  You can probably find them 
> easiest with a recursive grep against "@@".  This will help me 
> populate the storedconfigs database so I can reproduce this issue. 
>
> Thanks, 
> -Jeff 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/Pcexq3Ked8UJ.
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.

Hi there,

Just to report that I still see the same issue:


Debug: catalog supports formats: b64_zlib_yaml dot pson raw yaml; using
pson
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> allocator undefined for Proc
> /usr/lib/ruby/vendor_ruby/puppet/indirector/rest.rb:185:in
`is_http_200?''
> /usr/lib/ruby/vendor_ruby/puppet/indirector/rest.rb:100:in `find''
> /usr/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:197:in
`find''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:243:in `block in 
> retrieve_new_catalog''
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:351:in `block in
thinmark''
> /usr/lib/ruby/1.9.1/benchmark.rb:295:in `realtime''
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:350:in `thinmark''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:242:in 
> `retrieve_new_catalog''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:67:in
`retrieve_catalog''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:107:in 
> `prepare_and_retrieve_catalog''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:159:in `run''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (5 levels) in
run''
> /usr/lib/ruby/vendor_ruby/puppet/agent/locker.rb:20:in `lock''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (4 levels) in
run''
> /usr/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (3 levels) in
run''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:119:in `with_client''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:42:in `block (2 levels) in
run''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:84:in `run_in_fork''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:41:in `block in run''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in `call''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in
`controlled_run''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:39:in `run''
> /usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:353:in
`onetime''
> /usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:327:in
`run_command''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block (2 levels) 
> in run''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:456:in
`plugin_hook''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block in
run''
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:504:in `exit_on_fail''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `run''
> /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:132:in `run''
> /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:86:in
`execute''
> /usr/bin/puppet:4:in `<main>''
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
> Debug: report supports formats: b64_zlib_yaml pson raw yaml; using pson
>

System info, as requested:

root@ip-10-0-3-82:/etc/puppet/modules# lsb_release -irc
> Distributor ID:    Debian
> Release:    6.0.7
> Codename:    squeeze
> #
> root@ip-10-0-3-82:/etc/puppet/modules# ruby -v
> ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]
> #
> root@ip-10-0-3-82:/etc/puppet/modules# puppet -V
> 3.1.1
>

Only workaround, for me, so far is to delete the node from the puppet 
database. Cheers!!



On Thursday, November 29, 2012 2:34:50 PM UTC, John Lamb
wrote:
>
> OS: Red Hat Enterprise Linux Server release 6.3 (Santiago)
> Ruby: ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
> Puppet: puppet-3.0.1-1.el6.noarch
>
> I can get the facter output to you later today.
>
> For what it''s worth, I ran into this problem as I was developing a
class
> within an already-existing service. I referenced one or several resources 
> that didn''t actually exist (via the require metaparameter - I
tried to
> require Group[''git''],) and after fixing this issue I was
no longer able to
> get my puppet agent runs to work, even after commenting out all the changes
> I had made.
>
> I was able to "fix" this by trying "puppet node clean
broken.node.name",
> which failed, then I tested puppet node clean against a working node, which
> also failed, then on a whim I tried it against the broken node once more, 
> at which point it worked. Since then puppet has worked as usual.
>
> The error I got from puppet node clean is:
> Error: uninitialized constant ActiveRecord::Base
> Error: Try ''puppet help node clean'' for usage
>
> Interestingly, this morning our puppet deprecation report told us: "11
> ActiveRecord-based storeconfigs and inventory are deprecated." We
normally
> don''t have any deprecated storeconfigs. We have a total of 25
machines.  I
> don''t know if this is related to the issue at large.
>
> On Wednesday, November 28, 2012 8:09:38 PM UTC-5, Jeff McCune wrote:
>>
>> On Wed, Nov 28, 2012 at 10:55 AM, John Lamb <lam...@wfu.edu>
wrote:
>> > I am also seeing this bug on one of my nodes (worryingly, the
puppet
>> master 
>> > itself!) The relevant output of puppet agent -t --debug --trace 
>> --verbose 
>> > matches what Fabrice and Lee have also reported: 
>>
>> OK, there''s definitely a bug somewhere... 
>>
>> I''m going to work on reproducing this issue tomorrow.  Before
then,
>> could anyone affected by this "allocator undefined for Proc"
error
>> please let me know what exact versions of the operating system, Ruby, 
>> and Puppet they''re running? 
>>
>> If possible, if you could just privately email me the output of facter 
>> from an affected Puppet master that would be greatly helpful in 
>> reproducing this issue. 
>>
>> Finally, could you please send me (privately) a copy and paste of all 
>> exported resources in your manifests?  You can probably find them 
>> easiest with a recursive grep against "@@".  This will help
me
>> populate the storedconfigs database so I can reproduce this issue. 
>>
>> Thanks, 
>> -Jeff 
>>
>
On Thursday, November 29, 2012 1:09:38 AM UTC, Jeff McCune
wrote:
>
> On Wed, Nov 28, 2012 at 10:55 AM, John Lamb <lam...@wfu.edu
<javascript:>>
> wrote: 
> > I am also seeing this bug on one of my nodes (worryingly, the puppet 
> master 
> > itself!) The relevant output of puppet agent -t --debug --trace 
> --verbose 
> > matches what Fabrice and Lee have also reported: 
>
> OK, there''s definitely a bug somewhere... 
>
> I''m going to work on reproducing this issue tomorrow.  Before
then,
> could anyone affected by this "allocator undefined for Proc"
error
> please let me know what exact versions of the operating system, Ruby, 
> and Puppet they''re running? 
>
> If possible, if you could just privately email me the output of facter 
> from an affected Puppet master that would be greatly helpful in 
> reproducing this issue. 
>
> Finally, could you please send me (privately) a copy and paste of all 
> exported resources in your manifests?  You can probably find them 
> easiest with a recursive grep against "@@".  This will help me 
> populate the storedconfigs database so I can reproduce this issue. 
>
> Thanks, 
> -Jeff 
>
-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Hi there,

Just to report that I still see the same issue:


Debug: catalog supports formats: b64_zlib_yaml dot pson raw yaml; using
pson
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> allocator undefined for Proc
> /usr/lib/ruby/vendor_ruby/puppet/indirector/rest.rb:185:in
`is_http_200?''
> /usr/lib/ruby/vendor_ruby/puppet/indirector/rest.rb:100:in `find''
> /usr/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:197:in
`find''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:243:in `block in 
> retrieve_new_catalog''
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:351:in `block in
thinmark''
> /usr/lib/ruby/1.9.1/benchmark.rb:295:in `realtime''
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:350:in `thinmark''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:242:in 
> `retrieve_new_catalog''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:67:in
`retrieve_catalog''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:107:in 
> `prepare_and_retrieve_catalog''
> /usr/lib/ruby/vendor_ruby/puppet/configurer.rb:159:in `run''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (5 levels) in
run''
> /usr/lib/ruby/vendor_ruby/puppet/agent/locker.rb:20:in `lock''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (4 levels) in
run''
> /usr/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (3 levels) in
run''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:119:in `with_client''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:42:in `block (2 levels) in
run''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:84:in `run_in_fork''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:41:in `block in run''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in `call''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in
`controlled_run''
> /usr/lib/ruby/vendor_ruby/puppet/agent.rb:39:in `run''
> /usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:353:in
`onetime''
> /usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:327:in
`run_command''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block (2 levels) 
> in run''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:456:in
`plugin_hook''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block in
run''
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:504:in `exit_on_fail''
> /usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `run''
> /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:132:in `run''
> /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:86:in
`execute''
> /usr/bin/puppet:4:in `<main>''
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
> Debug: report supports formats: b64_zlib_yaml pson raw yaml; using pson
>

System info, as requested:

root@ip-10-0-3-82:/etc/puppet/modules# lsb_release -irc
> Distributor ID:    Debian
> Release:    6.0.7
> Codename:    squeeze
> #
> root@ip-10-0-3-82:/etc/puppet/modules# ruby -v
> ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]
> #
> root@ip-10-0-3-82:/etc/puppet/modules# puppet -V
> 3.1.1
>

Only workaround, for me, so far is to delete the node from the puppet 
database. Cheers!!

-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.