Issue #2211 has been updated by Daniel Grafe.

File 0001-Patch-Facter-is-collecting-zombies-by-PID-after-time.patch added

We were also facing this issue. Since we are initially setting up our machines 
locally with puppet agent we don't have a working network infrastructure (DNS 
resolving, interfaces, static host file...). This is causing the host tool to 
run for a longer time than the fact timeout allows and the greedy "block on 
waitall" thread is created. This thread should collect only Zombies but it is 
also collecting the child processes from the following puppet run. Puppet then 
fails on waitpid2 and terminates with an exception.

Please find attached our patch providing a workaround. It is basically 
realizing the exec after forking so we have a pid. The pid is saved in a class 
variable (big ugly hack!) so we can use this for waitpid in the case of a 
timeout.

This workaround is probably not the final solution for this issue and the exec 
for windows is still untested since we're running on linux only. 
----------------------------------------
Bug #2211: Facter timeouts reap all subprocesses thus confusing Puppet
https://projects.puppetlabs.com/issues/2211#change-60610

Author: John Florian
Status: Accepted
Priority: High
Assignee: Adrien Thebo
Category: library
Target version: 1.6.x
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