general/1474: No logging when killing above MaxSpareServers -- suggested patch included

["M.D.Parker" <md...@netcom.com>]

>Number:         1474
>Category:       general
>Synopsis:       No logging when killing above MaxSpareServers -- suggested patch included
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          change-request
>Submitter-Id:   apache
>Arrival-Date:   Mon Nov 24 12:50:00 PST 1997
>Last-Modified:
>Originator:     mdpc@netcom.com
>Organization:
apache
>Release:        1.3b3
>Environment:
Unix
>Description:
When the server become busy, an INFO message is generated to the error log
indicating that more server processes were created to be in line with the
configured MinSpareServers.  The current message generated implies three
factors...but this message really helps identify when the MinSpareServers is 
possibly set too low.

Now an administrator needs a way to determine when the MaxSpareServers is too
generous.  I suggest that this can be done by adding an INFO message to the
log when spare servers are killed off in http_main.c.

 
>How-To-Repeat:
No problem...
>Fix:
Yes...here is a suggested diff -c for this issue:

*** http_main.c.dist    Fri Nov 21 22:29:29 1997
--- http_main.new       Mon Nov 24 12:40:26 1997
***************
*** 3192,3197 ****
--- 3192,3211 ----
      }
      max_daemons_limit = last_non_dead + 1;
      if (idle_count > daemons_max_free) {
+ /*
+ * send out message for killing off high daemons
+ */
+ if (idle_spawn_rate >= 1) {
+                 aplog_error(APLOG_MARK, APLOG_NOERRNO|APLOG_INFO, server_conf,
+                     "server idle ( "
+                     "kill rate %d, idle %d, "
+                     "total %d )", idle_spawn_rate,
+                     idle_count, total_non_dead);  
+             }
+ /* 
+ *
+ */ 
+ 
        /* kill off one child... we use SIGUSR1 because that'll cause it to
         * shut down gracefully, in case it happened to pick up a request
         * while we were counting
%0
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]