www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: general/795: a flood of signals can confuse reclaim_child_processes()
Date Fri, 27 Jun 1997 08:10:18 GMT
It sucks to have to use gettimeofday() to find out how long select() took. 
I wonder if reclaim_child_processes is really necessary now that we've
eliminated many of the race conditions involving signals.

Oh yeah this definately happens, I've done a "while 1; kill -HUP" loop and
I see the errors in the log occasionally.  But I haven't been worried
about it yet.  masking is probably the best solution. 


On Thu, 26 Jun 1997, Nathan Kurz wrote:

> >Number:         795
> >Category:       general
> >Synopsis:       a flood of signals can confuse reclaim_child_processes()
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       medium
> >Responsible:    apache (Apache HTTP Project)
> >State:          open
> >Class:          sw-bug
> >Submitter-Id:   apache
> >Arrival-Date:   Thu Jun 26 15:20:00 1997
> >Originator:     nate@tripod.com
> >Organization:
> apache
> >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 
> >Audit-Trail:
> >Unformatted:

View raw message