Bug #1422

timeout of plugins during highload

Added by Peter Meier almost 4 years ago. Updated about 2 years ago.

Status:Closed Start date:07/14/2008
Priority:High Due date:
Assignee:Paul Nasrat % Done:

0%
Category:-
Target version:1.5.1
Keywords:timeout Affected Facter version:
Branch:
Votes: 0

Description

On a machine with a certain load (linux box, load > 2) facter will timeout with certain plugins. For example the timeout 1.5 for puppetversion isn’t enough, while 2.5 seems to be enough. Maybe the timeouts are just a litlle bit too tight, or there should be a global possibility to set a global minimum for the timeout of all the plugins which will take precedence over specific timeouts.

History

#1
Updated by James Turnbull almost 4 years ago

  • Status changed from Unreviewed to Accepted
  • Target version set to 14
  • Keywords set to timeout

#2
Updated by Al Hoang almost 4 years ago

Just an extra data point. I tried installing David Lutterkort’s “latest RPM packages”: http://et.redhat.com/~lutter/puppet/fc8/ for Facter and Puppet on a Fedora Core 8 EC2 instance for testing and ran into similar problems. I tried modifying the timeout in puppetversion.rb as suggested in this ticket up to 2.5 and even up to 10.5 and I still get the same Timed out. Adding the stack trace below for completeness

# facter 
Timed out seeking value for puppetversion
/usr/lib/ruby/site_ruby/1.8/puppet.rb:28: warning: already initialized constant PUPPETVERSION
/usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:139:in `searchpath': private method `split' called for nil:NilClass (NoMethodError)
    from /usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:130:in `eachdir'
    from /usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:73:in `load'
    from /usr/lib/ruby/site_ruby/1.8/puppet/util/feature.rb:53:in `method_missing'
    from /usr/lib/ruby/site_ruby/1.8/puppet/rails.rb:133
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
    from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:509:in `require'
    from /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:354:in `new_constants_in'
     ... 31 levels...
    from /usr/lib/ruby/gems/1.8/gems/facter-1.5/lib/facter.rb:92:in `to_hash'
    from /usr/lib/ruby/gems/1.8/gems/facter-1.5/bin/facter:121
    from /usr/bin/facter:19:in `load'
    from /usr/bin/facter:19

#3
Updated by Lawrence Ludwig almost 4 years ago

I am also seeing this bug, it appears on a puppetd 24.5 with constant high load.

#4
Updated by Luke Kanies almost 4 years ago

  • Priority changed from Normal to High
  • Target version changed from 14 to 1.5.1
  • 3 changed from Unknown to Easy

This should be straightforward to fix — we just make the timeouts optional instead of required.

At the least, I know I want a timeout on the Resolv call, because it can take up to 3 seconds to return.

#5
Updated by Paul Nasrat almost 4 years ago

  • Status changed from Accepted to In Topic Branch Pending Review

Proposed patch sent to list

git pull git://github.com/pnasrat/facter.git tickets/1422

#6
Updated by Luke Kanies almost 4 years ago

  • Status changed from In Topic Branch Pending Review to Code Insufficient
  • Assignee set to Paul Nasrat

I just tested the Timeout module, and if you default to a timeout of 0, then it’s equivalent to executing with no timeout at all.

Using that should greatly simplify your patch.

#7
Updated by Paul Nasrat almost 4 years ago

Simplified patch sent to list

git pull git://github.com/pnasrat/facter.git tickets/1422

#8
Updated by Paul Nasrat almost 4 years ago

  • Status changed from Code Insufficient to In Topic Branch Pending Review

#9
Updated by Luke Kanies almost 4 years ago

  • Status changed from In Topic Branch Pending Review to Closed

Merged.

#10
Updated by Alexander Schaber over 3 years ago

Please make this an configurable option somewhere .. Because I’m running puppet on 233 MHz / 32 MB embedded systems, which need around 25 to successfully do the job ..

Also available in: Atom PDF