Issue #2211 has been updated by John Florian.

Great news!  My boss lent a hand on this and I think we have a fix.  While I'm 
sure the attached patch we made is not necessarily the right place to add this 
trap, it does resolve the problem.  This note from "man 2 waitpid" explains his 
reasoning for the patch.

<pre>
POSIX.1-2001  specifies that if the disposition of SIGCHLD is set to SIG_IGN or
the SA_NOCLDWAIT flag is set for SIGCHLD (see sigaction(2)), then children that
terminate  do  not  become zombies and a call to wait() or waitpid() will block
until all children have terminated, and then fail with  errno  set  to  ECHILD.
(The  original  POSIX  standard left the behavior of setting SIGCHLD to SIG_IGN
unspecified.  Note that even though  the  default  disposition  of  SIGCHLD  is
"ignore",  explicitly  setting  the disposition to SIG_IGN results in different
treatment of zombie process children.)  Linux 2.6 conforms to  this  specifica-
tion.  However, Linux 2.4 (and earlier) does not: if a wait() or waitpid() call
is made while SIGCHLD is being ignored, the call behaves just as though SIGCHLD
were  not  being  ignored, that is, the call blocks until the next child termi-
nates and then returns the process ID and status of that child.
</pre>
----------------------------------------
Bug #2211: puppet won't install packages if network interface does not have an 
IP address bound
http://projects.reductivelabs.com/issues/2211

Author: John Florian
Status: Accepted
Priority: High
Assigned to: Luke Kanies
Category: 
Target version: unplanned
Complexity: Unknown
Affected version: 0.24.8
Keywords: 


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://reductivelabs.com/redmine/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