httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: Speding up SIGHUP handling in 1.1.1 (fwd)
Date Thu, 14 Nov 1996 06:31:04 GMT

> ----- Forwarded message from Rahul Dhesi -----
> Message-Id: <>
> To:
> Subject: Speding up SIGHUP handling in 1.1.1
> Date: Wed, 13 Nov 1996 07:13:01 -0800
> From: Rahul Dhesi <>
> This is not exactly a bug report, but suggestion.
> When Apache 1.1.1 is sent SIGHUP, each server process waits to complete
> its current transaction before exiting.  

Hmm, that's not what I see here, or how the code works.  When the parent
receives a SIGHUP, the children are all killed, the parent rereads the config
files, and then starts spawning children again.  If you send the parent a kill
-9, the parent will die but it won't bring down the children.  If you send the
parent a kill -15, the parent will kill all the children and then itself 
(We need a new metaphor, all this infanticide is making me uncomfortable.)

We are working on a "graceful restart", where the children can finish any
running requests before dying, which would be activated by sending the parent a
-USR1 signal.  It's somewhat unstable still, however.  When that happens, then
your desire for a timeout variable in that context might make some sense.  We
have noticed that we need separate timeouts for request reads and response
delivery (both are currently 1200 seconds by default, or set by TimeOut).  We
can't commit to any of this before 1.2 however, unless someone wants to submit
a patch :)

If you are interested in working on it, grab a snapshot of 1.2-beta from and develop your patches from there.  Thanks!


> If a TCP/IP connection is stuck
> or taking very long, that can hold up the server reinitialization for a
> long time, during which new incoming requests are not accepted.
> So I suggest a new variable ReinitTimeOut that places a limit on how
> long in-progress transactions will be permitted to continue after a
> SIGHUP has been received.
> Then ReinitTimeOut could be short (e.g., 120) while keeping TimeOut
> longer (e.g., 1200).  This will keep server reinitialization faster, at
> the expense of killing a few transactions that are taking too long.
> Rahul Dhesi <>
> ----- End of forwarded message from Rahul Dhesi -----


View raw message