httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: Graceful restarts and Listen's
Date Thu, 08 Aug 1996 10:46:49 GMT
Paul Sutton wrote:
> 
> Does the graceful restart stuff work with Listens? As far as I can
> see it doesn't, but I can't beleive no-one's noticed this so I
> must be doing something wrong.
> 
> Anyway, I think the problem is that there is now an fd element in the
> listener structure. When created, this has value 0 (in set_listener).
> When standalone_main() comes to listen, it only makes a socket
> for listeners with fd's of < 0.
> 
> A fix which seems to work is assigning new->fd = -1 in set_listener (patch
> below).

Whoops! As I said when I did the graceful restart code, I didn't actually test
listeners. Its gratifying that the rest of the code seems to work, tho...

Have you tried changing the Listen directives and then graceful restarting (coz
that was what all the code was designed to handle)?

I'll add your change ... it seems correct to me.

> 
> On a related note, is there a way we can force old children to die after a
> graceful restart? It seems when you -USR1 your server, it creates
> StartServers number of new children, but the old ones stay around until
> they have completed their current transaction. Fine. But if there are not
> currently in a transaction (perhaps waiting for the mutex lock, or doing a
> select()), they will wait a potentially long time. At least on the systems
> I've tried, it appears that the _new_ children seem to get the majority of
> the incoming connections. Since the parent will create new children as the
> load increases, it could be a long time before all the old children have
> accepted a connection and died.

Yeah, I have this problem on my system, too. Interestingly, if I have
debugging messages in the area of the select it seems to slow things down
enough to allow the children to be mopped up, but I haven't thought of a neat
way to do this properly (I suspect that if you are woken up from a select and
then do an OS call that doesn't handle the fd that you were woken up for, the
next process blocked in select is woken up). The other alternatives are to
send a signal to children which are not handling requests, or to have the
main process connect to the "old" servers until they are all dead (except the
ones handling transactions), or to count the old servers as ordinary children
and replace them as they die (which may cause some sluggishness during the
changeover).

Like I say, I haven't thought of a neat solution yet.

> 
> I don't know if this is a real problem: do the old children die reasonably
> quickly on real-world systems? Or is having a bunch of old-fashioned
> children around for a time not such a big deal? If it is a problem, we
> _could_ get the select code to timeout and do a generation check at
> regular intervals.  For the select this is easy -- just add a timeval
> argument, and put it in a loop
> 
>   do {
>     csd=select(...., &tv);
>     if (csd==0 && scoreboard_gen >= our_gen) die;
>   }
>   while (csd == 0);
> 
> sort of thing. But most OS's have the mutex stuff outside this, which is
> more difficult because it doesn't timeout. So perhaps it's not worth
> bothering about.

Good point.

Cheers,

Ben.

> 
> Paul
> UK Web
> 
> *** http_core.c Wed Aug  7 15:44:11 1996
> --- http_core.c.new     Thu Aug  8 09:22:13 1996
> ***************
> *** 998,1003 ****
> --- 998,1004 ----
>       else
>         new->local_addr.sin_addr.s_addr = get_virthost_addr(ips, NULL);
>       new->local_addr.sin_port = htons(atoi(ports));
> +     new->fd = -1;
>       new->next = listeners;
>       listeners = new;
>       return NULL;
> 
> 

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.            Apache Group member (http://www.apache.org)

Mime
View raw message