On 29/09/10 21:35, Jason Wright wrote:
> On Wed, Sep 29, 2010 at 7:12 AM, Brice Figureau
> <[email protected]> wrote:
>> Is the stacktrace complete?
> 
> Yes, that's all that made it into the error log.
> 
>> Is it always the same for all your 400 errors?
>> What version of puppet is running on the master (just to be able to
>> correlate line numbers)?
> 
> This particular master is running 2.6.1.
> 
>> In my 0.25 source code it is on this line:
>> raise ArgumentError, "The indirection name must be purely alphanumeric, not 
>> '%s'" % indirection unless indirection =~ /^\w+$/
> 
> Bah.  Our health check outputs a status file to
> https://server:9140/status for consumption by our load balancers and
> monitoring systems.  The server I've been testing with is running our
> new puppetmaster puppet module and it was missing the AliasMatch
> directive which handles /status.  Without the AliasMatch,
> puppetmasterd logs the message you list above every time the load
> balancers or monitoring systems access /status.
> 
> So this looks like the wrong stack trace.  We like hosting the /status
> file on the same virtual host as puppetmasterd, but it looks like we
> may want to move it to a different one if it's causing puppetmasterd
> to crash.

It's harmless for the master. The issue is that it returns an HTTP error
400 to your load-balancer which might not like it :)

> Try this one instead:
> 
> /usr/lib/ruby/1.8/puppet/indirector/yaml.rb:22:in `find'
> /usr/lib/ruby/1.8/puppet/indirector/indirection.rb:208:in `find_in_cache'
> /usr/lib/ruby/1.8/puppet/indirector/indirection.rb:184:in `find'
> /usr/lib/ruby/1.8/puppet/indirector.rb:50:in `find'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:90:in `find_node'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:114:in
> `node_from_request'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:32:in `find'
> /usr/lib/ruby/1.8/puppet/indirector/indirection.rb:193:in `find'
> /usr/lib/ruby/1.8/puppet/indirector.rb:50:in `find'
> /usr/lib/ruby/1.8/puppet/network/http/handler.rb:101:in `do_find'
> /usr/lib/ruby/1.8/puppet/network/http/handler.rb:68:in `send'
> /usr/lib/ruby/1.8/puppet/network/http/handler.rb:68:in `process'
> /usr/lib/ruby/1.8/puppet/network/http/rack.rb:51:in `call'
> /usr/lib/ruby/1.8/phusion_passenger/rack/request_handler.rb:95:in
> `process_request'
> /usr/lib/ruby/1.8/phusion_passenger/abstract_request_handler.rb:207:in
> `main_loop'
> /usr/lib/ruby/1.8/phusion_passenger/rack/application_spawner.rb:118:in `run'
> /usr/lib/ruby/1.8/phusion_passenger/rack/application_spawner.rb:69:in
> `spawn_application'
> /usr/lib/ruby/1.8/phusion_passenger/utils.rb:184:in `safe_fork'
> /usr/lib/ruby/1.8/phusion_passenger/rack/application_spawner.rb:62:in
> `spawn_application'
> /usr/lib/ruby/1.8/phusion_passenger/rack/application_spawner.rb:45:in
> `spawn_application'
> /usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:159:in 
> `spawn_application'
> /usr/lib/ruby/1.8/phusion_passenger/spawn_manager.rb:287:in
> `handle_spawn_application'
> /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:352:in `__send__'
> /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:352:in `main_loop'
> /usr/lib/ruby/1.8/phusion_passenger/abstract_server.rb:196:in
> `start_synchronously'
> /usr/lib/phusion_passenger/passenger-spawn-server:61

It crashes on malformed/corrupted/inexistant yaml when reloading the
cached node.

This node cache file is locked, so it shouldn't fail. Maybe the code has
a race condition I didn't see. I'll have a better look to the
filelocking code.

I'm not sure, but I think you can remove the node cache quite safely if
you want to continue your load testing (comment the
Puppet::Node.cache_class affectation in lib/puppet/application/master.rb).

It would be great if you could add some debug statements to the
lib/puppet/indirector/yaml.rb file around line 22 to show what the YAML
look like, and/or what cache it was trying to load.
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to