Return-Path: Delivered-To: apmail-spamassassin-dev-archive@www.apache.org Received: (qmail 52711 invoked from network); 3 Sep 2004 01:16:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 3 Sep 2004 01:16:17 -0000 Received: (qmail 38158 invoked by uid 500); 3 Sep 2004 01:16:05 -0000 Delivered-To: apmail-spamassassin-dev-archive@spamassassin.apache.org Received: (qmail 38128 invoked by uid 500); 3 Sep 2004 01:16:04 -0000 Mailing-List: contact dev-help@spamassassin.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: List-Id: "SpamAssassin Development" dev@spamassassin.apache.org Delivered-To: mailing list dev@spamassassin.apache.org Received: (qmail 38113 invoked by uid 99); 3 Sep 2004 01:16:04 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=NO_REAL_NAME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of apache@bugzilla.spamassassin.org designates 64.142.3.173 as permitted sender) Received: from [64.142.3.173] (HELO bugzilla.spamassassin.org) (64.142.3.173) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 02 Sep 2004 18:16:04 -0700 Received: by bugzilla.spamassassin.org (Postfix, from userid 48) id CBC28840D6; Thu, 2 Sep 2004 18:16:02 -0700 (PDT) From: bugzilla-daemon@bugzilla.spamassassin.org To: dev@spamassassin.apache.org Subject: [Bug 3743] Spamd not cleaning up defunct processes X-Bugzilla-Reason: AssignedTo Message-Id: <20040903011602.CBC28840D6@bugzilla.spamassassin.org> Date: Thu, 2 Sep 2004 18:16:02 -0700 (PDT) X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N http://bugzilla.spamassassin.org/show_bug.cgi?id=3743 ------- Additional Comments From felicity@kluge.net 2004-09-02 18:16 ------- Subject: Re: Spamd not cleaning up defunct processes On Thu, Sep 02, 2004 at 05:53:04PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote: > We suspect the problem has to do with a SIGCHLD being received whilst the spamd > process is already in the wait state cleaning up another SIGCHLD signal; hence > the second SIGCHLD is missed. We have made the following changes to use the > waitpid call instead which will reap all children that need a cleanup. We are > currently testing the change and will report back if it fixes the problem. Hrm, ok. As an FYI, child_handler (and the rest of the pre-fork stuff) was essentially pulled right out of the perlipc doc. Looking at the code, it does seem like we ought to wait until the end to reset the handler too... > sub child_handler { > my ($sig) = @_; > $SIG{CHLD} = \&child_handler; # reset as necessary yeah there... according to the perlipc page, there's a SysV issue which makes it have to go after the wait, which we apparently don't do (why didn't I do that?). :( > - logmsg("server hit by SIG$sig"); > - while((my $pid = waitpid(-1, &WNOHANG)) > 0) { # reap the child > - delete $children{$pid}; # remove the child out of the > pool > - logmsg(" cleaned up child pid $pid"); > - } > + my $pid = wait; # reap the child > + delete $children{$pid}; # remove the child out of the pool > + logmsg("server hit by SIG$sig, pid $pid"); Errr... I liked the waitpid() version because it can do NOHANG, and because the first handler call could catch more children if they exited around the same time. wait() causes the process to hang for a child, which makes me think of bad things depending on how the handler is called. I'd say the first thing to try is just moving the handler reset to the bottom of the function, and see if that helps. If not, progress forward. :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.