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

Search Discussions

  • Jeff McCune at Oct 18, 2012 at 4:31 pm
    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 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.
  • Fabrice Bacchella at Oct 22, 2012 at 3:28 pm
    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 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.
  • Jeff McCune at Oct 23, 2012 at 12:19 am
    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.
  • Jeff McCune at Oct 24, 2012 at 3:50 pm
    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
    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 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.
  • Fabrice Bacchella at Oct 25, 2012 at 11:42 am

    Le 24 oct. 2012 à 17:49, Jeff McCune 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.
  • Jeff McCune at Oct 25, 2012 at 4:41 pm

    On Thu, Oct 25, 2012 at 4:42 AM, Fabrice Bacchella 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.
  • Fabrice Bacchella at Oct 25, 2012 at 6:26 pm

    Le 25 oct. 2012 à 18:40, Jeff McCune a écrit :

    On Thu, Oct 25, 2012 at 4:42 AM, Fabrice Bacchella 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.
  • Jeff McCune at Oct 25, 2012 at 6:46 pm

    On Thu, Oct 25, 2012 at 11:26 AM, Fabrice Bacchella 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.
  • Lee Boynton at Nov 27, 2012 at 2:30 pm
    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.
  • Jeff McCune at Nov 27, 2012 at 4:33 pm

    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 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 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.
  • Lee Boynton at Nov 27, 2012 at 4:39 pm
    delete from hosts where name = 'the.node.name';

    On 27 November 2012 16:33, Jeff McCune 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 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 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.
  • Jeff McCune at Nov 27, 2012 at 5:02 pm

    On Tue, Nov 27, 2012 at 8:39 AM, Lee Boynton 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.
  • Lee Boynton at Nov 27, 2012 at 4:59 pm
    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 wrote:
    On Tue, Nov 27, 2012 at 8:39 AM, Lee Boynton 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.
  • Lee Boynton at Nov 27, 2012 at 5:13 pm
    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 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 wrote:
    On Tue, Nov 27, 2012 at 8:39 AM, Lee Boynton 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.
  • Jeff McCune at Nov 27, 2012 at 6:50 pm

    On Tue, Nov 27, 2012 at 9:06 AM, Lee Boynton 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.
  • Lee Boynton at Nov 28, 2012 at 10:49 am
    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 wrote:
    On Tue, Nov 27, 2012 at 9:06 AM, Lee Boynton 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.
  • John Lamb at Nov 28, 2012 at 6:55 pm
    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 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.
  • Jeff McCune at Nov 29, 2012 at 1:10 am

    On Wed, Nov 28, 2012 at 10:55 AM, John Lamb 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.
  • John Lamb at Nov 29, 2012 at 2:34 pm
    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.
  • Sans at Oct 6, 2013 at 5:23 pm
    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.
  • Sans at Oct 6, 2013 at 5:21 pm
    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 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.
  • Fabrice Bacchella at Nov 29, 2012 at 10:57 am

    Le 27 nov. 2012 à 19:44, Jeff McCune 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedOct 18, '12 at 12:34p
activeOct 6, '13 at 5:23p
posts23
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase