httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: night of the dead Apache
Date Sat, 01 Nov 1997 02:52:28 GMT
Uh, wait.

You're running -X and expecting timeouts?  They don't happen under -X with
my new timeout code... although I didn't intend that, I just realised it. 
There's no parent to do the timeout. 

Does removing OPTIMIZE_TIMEOUTS fix a normal multiprocess server? 

Dean

On Fri, 31 Oct 1997, Roy T. Fielding wrote:

> >Can you isolate out my new timeout code by editing httpd.h and commenting
> >out the OPTIMIZE_TIMEOUTS definition at the bottom?
> 
> Yep.  It still blocks at the same place, but now it gets timed out.
> 
> read(3, " G E T   / I c o n s / N".., 4096)     = 281
> sigaction(SIGUSR1, 0xEFFFCA90, 0xEFFFCB90)      = 0
> time()                                          = 878350565
> alarm(30)                                       = 15
> alarm(0)                                        = 30
> time()                                          = 878350565
> stat("/home/www/documentroot/Icons/N2Hplus.xbm", 0x00097FC0) = 0
> lstat("/home/www/documentroot/Icons/N2Hplus.xbm", 0xEFFFEAA0) = 0
> open("/home/www/documentroot/Icons/N2Hplus.xbm", O_RDONLY) = 5
> mmap(0x00000000, 591, PROT_READ, MAP_PRIVATE, 5, 0) = 0xEF530000
> alarm(30)                                       = 0
> alarm(0)                                        = 30
> alarm(30)                                       = 0
> alarm(30)                                       = 30
> alarm(0)                                        = 30
> lseek(5, 0, SEEK_CUR)                           = 0
> close(5)                                        = 0
> time()                                          = 878350565
> poll(0xEFFFCB60, 1, 0)                          = 0
> write(3, " H T T P / 1 . 1   2 0 0".., 877)     = 877
> time()                                          = 878350565
> write(17, " 1 2 8 . 1 9 5 . 2 1 . 1".., 90)     = 90
> time()                                          = 878350565
> times(0xEF62002C)                               = 285595803
> munmap(0xEF530000, 591)                         = 0
> time()                                          = 878350565
> sigaction(SIGUSR1, 0xEFFFEB80, 0xEFFFEC80)      = 0
> alarm(15)                                       = 0
> read(3, 0x0008E750, 4096)       (sleeping...)
> signotifywait()                                 = 14
>     Received signal #14, SIGALRM, in read() [caught]
> lwp_sigredirect(1, SIGALRM)                     = 0
> read(3, 0x0008E750, 4096)                       Err#4 EINTR
> sigprocmask(SIG_SETMASK, 0xEF5659D4, 0x00000000) = 0
> sigaction(SIGPIPE, 0xEFFFA2E8, 0xEFFFA3E8)      = 0
> close(3)                                        = 0
> 
> 
> It appears to be doing this after the last request on each kept-alive
> connection, since the truss shows this on the last 4 requests.  One weird
> effect is that the third and fourth child requests are served last,
> because I am running in -X mode and they are getting blocked as new
> connections while all the others are serviced on a keep-alive connection.
> But that is unrelated to the problem (it just confused me for a bit).
> 
> ....Roy
> 


Mime
View raw message