Error: can't instantiate uninitialized class

63 views
Skip to first unread message

Luca Gioppo

unread,
Dec 6, 2012, 6:14:51 AM12/6/12
to puppet...@googlegroups.com
OK I'm getting mad.

All of a sudden after a few mods I received this error from the puppet_master.

I reverted all the changes done up to a last working set but no prize still this error and I cannot understand what is happening it seems that it manages to finish the catalog but than it stops.

Here is a chunk of the output any idea on ohw to raise the level of debug and getting something more useful?
Puppet version 3.0.0
Thanks
Luca

Compiled catalog for jbossm.cortile.cloudlabcsi.local in environment production in 1.53 seconds
Info: Caching catalog for jbossm.cortile.cloudlabcsi.local
Debug: Searched for resources in 0.01 seconds
Error: can't instantiate uninitialized class
Debug: Finishing transaction 69873076055740

jcbollinger

unread,
Dec 6, 2012, 9:22:04 AM12/6/12
to puppet...@googlegroups.com


That error message is being emitted by the agent, not the master.  Run the agent with the --debug flag to get the most detailed information available, but it looks like you may already be doing that.

That doesn't look like a Puppet error message, however.  Puppet doesn't have a sense of "initializing" classes, nor really of "instantiating" them.  The latter, especially, is an OO concept, and Puppet's "classes" are not classes in the OO sense.

I would guess, therefore, that the error is being emitted at a lower level of the software stack, probably in Ruby itself.  If it's there then it could arise from a Puppet bug, a Ruby bug, or an incompatibility between Puppet and your Ruby implementation.  Which Ruby is that, by the way?


John

Luca Gioppo

unread,
Dec 6, 2012, 10:28:29 AM12/6/12
to puppet...@googlegroups.com
Ruby version 1.8.7 on both master and agent.

But on the agent I get:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: can't instantiate uninitialized class
Debug: Using cached catalog for jbossm.cortile.cloudlabcsi.local
Using cached catalog

So the problem should be in the puppet master and not in the agent.

Luca

Luca Gioppo

unread,
Dec 7, 2012, 3:30:43 AM12/7/12
to puppet...@googlegroups.com
Anyone has a good hint on how to get better debug info on this problem?
Other nodes work correctly so puppet master is not broken just the catalog of the node I'm working on, but cannot manage to find the bug.

Luca

Il giorno giovedì 6 dicembre 2012 12:14:51 UTC+1, Luca Gioppo ha scritto:

jcbollinger

unread,
Dec 7, 2012, 10:31:20 AM12/7/12
to puppet...@googlegroups.com


On Thursday, December 6, 2012 9:28:29 AM UTC-6, Luca Gioppo wrote:
Ruby version 1.8.7 on both master and agent.

But on the agent I get:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: can't instantiate uninitialized class
Debug: Using cached catalog for jbossm.cortile.cloudlabcsi.local
Using cached catalog

So the problem should be in the puppet master and not in the agent.


That's fundamentally different from what you wrote before.  Did the behavior indeed change between your posts?  Are we to take the second as the behavior you are seeing now?  Is it consistent?

Moreover Google tells me that the reported error message indeed does not appear in Puppet's code base, but that it does appear in the code of at least a couple of different Ruby implementations.  Given that yours is the first report I have seen of Puppet emitting that message, I am inclined to suspect that the bug is in Ruby code that does not belong to Puppet itself -- it could be in a custom type or provider, a Ruby DSL manifest, or a template.

As for debugging, you can use the --debug flag for the master, too.  Even before that, however, you should look in its logs; any details about what may be going wrong on the master will be reported there, not in the agents' logs.  Also, you should try to find the minimal set of modules / classes that need to be assigned to the node (in its node block or by your ENC) to trigger the error.


John

Luca Gioppo

unread,
Dec 10, 2012, 9:22:25 AM12/10/12
to puppet...@googlegroups.com
No the behaviour has been always the same:
On the server I get:

Compiled catalog for jbossm.cortile.cloudlabcsi.
local in environment production in 1.53 seconds
Info: Caching catalog for jbossm.cortile.cloudlabcsi.local
Debug: Searched for resources in 0.01 seconds
Error: can't instantiate uninitialized class
Debug: Finishing transaction 69873076055740


On the  agent:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: can't instantiate uninitialized class
Debug: Using cached catalog for jbossm.cortile.cloudlabcsi.
local
Using cached catalog

What happens is the puppet_master says that it finishes the catalog compilation and than throws the error and the agent receives the error (the remote 400 error) and uses the cached catalog.
Debug all up in both master and agent.
If logs are on /var/log/puppet/masterhttp.log or rails.log nothing usefull no error (the rails.log is empty and I do not know how to enable logging on ruby)

It colud be a template??? I'll check it, but have no clue.
Thanks
Luca


Il giorno giovedì 6 dicembre 2012 12:14:51 UTC+1, Luca Gioppo ha scritto:

jcbollinger

unread,
Dec 10, 2012, 5:41:14 PM12/10/12
to puppet...@googlegroups.com


On Monday, December 10, 2012 8:22:25 AM UTC-6, Luca Gioppo wrote:
No the behaviour has been always the same:

Ok.
 

It colud be a template??? I'll check it, but have no clue.


Yes.  Templates can execute arbitrary Ruby code, so they can trigger any error that Ruby can throw.  Whether the bug is likely to be in a template, on the other hand, depends heavily on your templates.

Again, try to find the minimal set of resources that must be assigned to the node to cause the problem.  Start by verifying that there is no error when the node's catalog is empty.  Then try each module that is normally assigned to the node, individually (to the extent that's possible).  Focus first on any modules for which the troublesome node has unusual configuration relative to most nodes.  If the problem is localized in one module (which is likely), then you should be able to identify the module that way.


John

Reply all
Reply to author
Forward
0 new messages