httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <r...@imdb.com>
Subject Re: SIGUSR1
Date Thu, 21 Nov 1996 16:39:16 GMT
Ben Laurie wrote:

>> All in all, this looks very hacked together and unless someone has a
>> quick fix we should disable it and take a fresh look at the whole
>> forking model for 2.0, which we'd have to do anyway for threading.
>
>I see no mileage in disabling it - if users don't like it they can not use it.
>It works fine if SIGUSR1 and SIGHUP are not mixed.

As it is, we have an easter egg that holds a razor blade. When I tried it
(ages ago) it all looked to be working well, then all my servers died at
midnight.

Ben, if you really don't want to see it disabled, can we 
#ifdef it off by default so that only the people who understand the
risks and want to use it switch it on. The more I think about it, the more
I feel we should err on the side of caution, even if they don't read the
code, someone will sooner or later experiment with that signal and leave
a timebomb ticking till the next SIGHUP. People coming from other servers
may already be used to SIGUSR1.

The feature is in now, so it can (in principle) be bugfixed at any
time before 1.2 gets released.

+1 on the following patch:


*** http_main.c.orig	Thu Nov 21 16:28:35 1996
--- http_main.c	Thu Nov 21 16:29:33 1996
***************
*** 1205,1213 ****
--- 1205,1215 ----
  #ifdef NO_USE_SIGACTION
      signal(SIGTERM,(void (*)())sig_term);
      signal(SIGHUP,(void (*)())restart);
+ #ifdef RISKY_GRACEFUL_RESTARTS
      signal(SIGUSR1,(void (*)())graceful_restart);
  	/* USE WITH EXTREME CAUTION. Graceful restarts are known to break */
  	/*  problems will be dealt with in a future release */
+ #endif
  #else
      memset(&sa,0,sizeof sa);
      sa.sa_handler=(void (*)())sig_term;




Mime
View raw message