Issue #4462 has been updated by Peter Meier.
Peter Meier wrote: > I tested it and puppet now doesn't anymore with a stacktrace, but it still > exits directly after printing the error. Wouldn't it be better to just fail > the resource on which the timeout appears as it is done at some other places. Another note on that: This seems to happen mainly during the creation of the internal types, so when the catalog is being parsed and the individual resource type objects are being created and puppet is for example asking the master for metadata about a file. This means that it is definitely not the same as a usual timeout during fetching the source of a file resource, so failing the resource and anything else depending on it doesn't yet seem to be possible. However, still puppet usually seems to be stalled for a very long time if that error happens and it then prints out for example: <pre> [...] info: Caching catalog for foo.bar.ch err: Could not run Puppet configuration client: Connection timed out Could not retrieve file metadata for puppet:///modules/apache/vhosts.d/CentOS.Final/0-default.conf: Connection timed out at /srv/puppet/development/modules/public/apache/manifests/vhost/file.pp:72 # </pre> If I hook tcpdump on the master in front of nginx I can see that ningx sent something to the client. However the client remains silent about that and using strace I can see that the client is waiting for an answer and is then running into the http timeout after a very long time (more than the usual configtimeout and the usual 60s). It occures to me that this behavior has been somehow introduced into 2.6 as I only remember resource timeouts (like fetching a file's source) before 2.6. Furthermore, this is getting a bit annoying as I have a lot of clients on rather high latency networks and if they exit after that timeout the whole run is aborted. :/ But as I also upgraded other things (such as client's/master's ruby version or the different gems on the master) when upgrading puppet to 2.6, so the problem might be also somewhere else and debugging is therefore a bit difficult. Anyway, I will dig into that problem a bit further and my next step would be to dump the traffic on both sites, so I can see if really a package is getting lost or ruby/puppet-client is stalled somewhere else. If there are any other ideas around how to track things down I would be happy for further suggestions. So besides looking for the cause for that timeout, I think puppet should somehow not abort its run, when such a timeout happens. ---------------------------------------- Bug #4462: uncaught timeout excpetion http://projects.puppetlabs.com/issues/4462 Author: Peter Meier Status: Ready for Checkin Priority: Normal Assigned to: Category: Target version: 2.6.1 Affected version: 2.6.1rc1 Keywords: Branch: http://github.com/jes5199/puppet/tree/ticket/2.6.x/4462 I encounter from time to time an uncaught timeout exception: <pre> /usr/lib/ruby/1.8/timeout.rb:60:in `open': execution expired (Timeout::Error) from /usr/lib/ruby/1.8/net/http.rb:560:in `connect' from /usr/lib/ruby/1.8/net/http.rb:560:in `connect' from /usr/lib/ruby/1.8/net/http.rb:553:in `do_start' from /usr/lib/ruby/1.8/net/http.rb:542:in `start' from /usr/lib/ruby/1.8/net/http.rb:1035:in `request' from /usr/lib/ruby/1.8/net/http.rb:772:in `get' from /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:71:in `find' from /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find' ... 42 levels... from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:397:in `exit_on_fail' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' from /usr/sbin/puppetd:4 </pre> I think this one should be caught and translated into a puppet error?! -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
