From nobody@hyperreal.com Thu Jun 26 15:14:32 1997 Received: (from nobody@localhost) by hyperreal.com (8.8.5/8.8.5) id PAA07752; Thu, 26 Jun 1997 15:14:32 -0700 (PDT) Message-Id: <199706262214.PAA07752@hyperreal.com> Date: Thu, 26 Jun 1997 15:14:32 -0700 (PDT) From: Nathan Kurz Reply-To: nate@tripod.com To: apbugs@hyperreal.com Subject: a flood of signals can confuse reclaim_child_processes() X-Send-Pr-Version: 3.2 >Number: 795 >Category: general >Synopsis: a flood of signals can confuse reclaim_child_processes() >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Thu Jun 26 15:20:00 1997 >Last-Modified: Sun Aug 17 13:50:18 PDT 1997 >Originator: nate@tripod.com >Organization: >Release: 1.2.0 >Environment: any >Description: The select calls in reclaim_child_processes() can be cut short by signal interruptions. If enough signals are coming, none of the wait times will happen and the lot's of unnecessary errors will be logged. The child processes should still die just the same, though. >How-To-Repeat: I'm not sure if you can. It might only be a theoretical problem ;) I found it by in a piece of code I wrote that was very similar to this routine and haven't actually tested it in Apache. >Fix: I had success masking off certain signals around the select() statement. In particular, I call sigprocmask to mask and unmask SIGHUP and SIGTERM before and after the select(). Apache might want to do these and SIGUSR1 >Audit-Trail: State-Changed-From-To: open-analyzed State-Changed-By: dgaudet State-Changed-When: Fri Aug 1 03:08:29 PDT 1997 State-Changed-Why: Yep, a patch is on the table now for 1.2.2. Ooops I missed SIGTERM. Dean State-Changed-From-To: analyzed-closed State-Changed-By: dgaudet State-Changed-When: Sun Aug 17 13:50:17 PDT 1997 State-Changed-Why: Fixed in 1.2.2 and 1.3a2. As discussed on new-httpd I didn't touch SIGTERM ... Dean >Unformatted: