Issue #2211 has been updated by John Florian.

This dangerous bug is still occurring with:

puppet-2.7.13-1.fc17
facter-1.6.6-1.fc17
ruby-1.9.3.194-11.fc17

This will commonly look something like this now:

<pre>
Jun 14 14:45:08 puppet puppet-master[9646]: (//myhost.example.com/Puppet) Could 
not retrieve catalog from remote server: Could not intern from pson: Could not 
autoload package: Could not autoload 
/usr/share/ruby/vendor_ruby/puppet/provider/package/aptrpm.rb: Could not 
autoload rpm: No child processes
Jun 14 14:45:08 puppet puppet-master[9646]: (//myhost.example.com/Puppet) Using 
cached catalog
Jun 14 14:45:08 puppet puppet-master[9646]: (//myhost.example.com/Puppet) 
Failed to apply catalog: Parameter ensure failed: Validate method failed for 
class ensure: undefined method `satisfies?' for nil:NilClass
</pre>

At least that's the case when it kills one of its own children.  I have to 
wonder how often a critical server PID gets killed instead, which would is just 
the opposite of what you'd want puppet to do in an enterprise.

----------------------------------------
Bug #2211: Facter timeouts reap all subprocesses thus confusing Puppet
https://projects.puppetlabs.com/issues/2211#change-65053

Author: John Florian
Status: Accepted
Priority: High
Assignee: 
Category: library
Target version: 
Keywords: 
Branch: 
Affected Facter version: 


It is no longer possible to have puppet install packages via yum/rpm if the 
network interface is not bound to an IP address.  Our use case requires using 
puppet in the non-daemon mode and this is possible for us because the system 
will have all necessary manifests and other necessary files locally.  This 
worked just fine with 0.24.6 on Fedora 10, but began failing upon the upgrade 
to 0.24.8.

See the attachments for failure messages and a code diff that seems to have 
introduced the regression.  If I revert this one change, things work nicely 
once again.  Looks like a very simple fix if it weren't for the ominous looking 
comment in the code. :-)


-- 
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.

Reply via email to