Fix for #2661 and related issues

If setup code for a process depends on network connectivity
it needs to be protected with a rescue clause as much as the
main body of the process.

Further, Timeout exceptions aren't under StandardError and thus
aren't caught by an un-typed rescue clause.  This doesn't matter
if we've morphed the exception, but will cause the program to
fail if we haven't.

There are many places where these concerns _might_ cause a problem
but in most cases they never will in practice; this patch addresses
the five cases where I have been able to confirm that it actually
can cause the client daemon to exit and two more where I suspect
(but can not prove) that it could.

This is an extension of the prior patch to cover additional cases
found by automated testing (repeated catalog runs with a 1% chance
of timeout forced on all timeout-bound operations, ~5000 runs).

The new cases recurred multiple times (>100 each) and in a final pass
with these corrected (~2500 runs) no additional cases were found.

1 files changed, 2 insertions, 3 deletions

diff --git a/lib/puppet/configurer/fact_handler.rb b/lib/puppet/configurer/fact_handler.rb
index 8e0fef71d..cbb627680 100644
--- a/lib/puppet/configurer/fact_handler.rb
+++ b/lib/puppet/configurer/fact_handler.rb
@@ -11,14 +11,13 @@ module Puppet::Configurer::FactHandler
     end
 
     def find_facts
-        reload_facter()
-
         # This works because puppetd configures Facts to use 'facter' for
         # finding facts and the 'rest' terminus for caching them.  Thus, we'll
         # compile them and then "cache" them on the server.
         begin
+            reload_facter()
             Puppet::Node::Facts.find(Puppet[:certname])
-        rescue => detail
+        rescue Exception => detail
             puts detail.backtrace if Puppet[:trace]
             raise Puppet::Error, "Could not retrieve local facts: %s" % detail
         end