Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 86208 invoked from network); 1 Jun 2007 14:50:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Jun 2007 14:50:35 -0000 Received: (qmail 11521 invoked by uid 500); 1 Jun 2007 14:50:35 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 11459 invoked by uid 500); 1 Jun 2007 14:50:35 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 11445 invoked by uid 99); 1 Jun 2007 14:50:35 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 07:50:35 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [209.133.199.10] (HELO jimsys.jagunet.com) (209.133.199.10) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 07:50:30 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by jimsys.jagunet.com (Postfix) with ESMTP id D11717A56DA for ; Fri, 1 Jun 2007 10:50:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070601141930.GA24876@infiltrator.gizzard.com> References: <200705302209.l4UM9EdY012898@devsys.jaguNET.com> <20070601141930.GA24876@infiltrator.gizzard.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <60C08DB3-CFFB-45E0-A5F5-A0106CCC0A9F@jaguNET.com> Content-Transfer-Encoding: 7bit From: Jim Jagielski Subject: Re: [Fwd: Apache httpd vulenrabilities] Date: Fri, 1 Jun 2007 10:50:09 -0400 To: dev@httpd.apache.org X-Mailer: Apple Mail (2.752.2) X-Virus-Checked: Checked by ClamAV on apache.org On Jun 1, 2007, at 10:19 AM, Colm MacCarthaigh wrote: > On Fri, Jun 01, 2007 at 10:05:26AM -0400, Jim Jagielski wrote: >> - if (ap_scoreboard_image->servers[n].status != SERVER_DEAD && >> - kill((pid = ap_scoreboard_image->parent[n].pid), 0) == -1) { >> - ap_update_child_status(n, SERVER_DEAD, NULL); >> - /* just mark it as having a successful exit status */ >> - bzero((char *) status, sizeof(ap_wait_t)); >> - return(pid); >> - } >> + pid = ap_scoreboard_image->parent[n].pid; >> + if (ap_scoreboard_image->servers[n].status != SERVER_DEAD) { >> + if (in_pid_table(pid)) { >> + if (kill(pid, 0) == -1) { >> + ap_update_child_status(n, SERVER_DEAD, NULL); >> + /* just mark it as having a successful exit >> status */ >> + bzero((char *) status, sizeof(ap_wait_t)); >> + return(pid); >> + } > > Should we get rid of it from the table here? Can we get away without > removing stale pids in general? What if they are recycled by the OS > for something else? > No, that's a good point. We should likely remove the pid from our table once the child goes away.