os-linux/6176: Problem, possibly related to ticket 4642

[David Ernst <dr...@bloomington.in.us>]

>Number:         6176
>Category:       os-linux
>Synopsis:       Large memory growth, followed by occaisonal server failures
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Sun Jun 11 14:20:00 PDT 2000
>Closed-Date:
>Last-Modified:  
>Originator:     james@jamesarmstrong.com
>Release:        1.3.6 (default version for redhat 6.0)
>Organization:
apache
>Environment:
Standard out-of-the-box RedHat Linux 6.0.  Apache is the version delivered with

RH 6.0.
>Description:
We have observed that the version of apache that was installed with RedHat 6.0
will experience
growth of the shared memory segment; we have seen shared segments in sizes exce
eding 100 Mbytes in
less than 5 hours of operation.  Nightly, when we rotate logs, we would perform
 a kill -HUP
to start a new logfile; this would freeze or crash the server (Dell Pentium Pow
eredge 4300
single processor with 256 MBytes RAM, 512 MByte configured swap, 18 Gbytes RAID
 5 using RedHat
drivers.)

I did not see anything in the bug database for this, although I did see some si
milar
on Solaris.
>How-To-Repeat:
If needed, I can provide a copy of our httpd.conf file, we do virtual hosting f
or several domains.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
 Hello, we've been having quite a bit of trouble with our apache v 1.3.6
 running on redhat linux 6.0.  The problem sounds a great deal like
 what is being described below.  
 
 We believe we have learned something about the problem, and that is
 that sending multiple HUP signals to httpd in relatively rapid
 succession seems to cause httpd to grow very quickly in size, in many
 cases causing the machine to effectively crash and require reboot.  We
 first discovered this through a monthly log rotating script which we
 wrote ourselves and used happily on our redhat 5.1 system.  The script
 rotates over 100 httpd access logs (doing some log analysis on each
 one) and sends a HUP to httpd for EVERY ONE of the log files.  
 
 Once we had the suspicion, I sat at my command line as root and
 repeatedly typed
 
 killall -HUP httpd 
 
 Perhaps I sent two of these commands per second for about 10 seconds.
 Sure enough, ps aux started reporting that httpd had doubled in size.
 If I left it alone, it would not grow any further.  But as soon as I
 started sending it HUP signals again, the memory would grow
 furthermore. 
 
 Naturally, stopping the daemon and restarting it "fixed" the problem,
 ie, ps aux once again showed the standard httpd footprint.  
 
 We have modified our scripts to send fewer HUPs, and I suspect we will
 no longer have any problem with this.  All the same, it would be nice
 to know that someone is addressing it, and that we may have played a
 part in getting it fixed.  Thanks,
 
 David Ernst
 HoosierNet, Inc.  
 
 
 
 ----------------------------------------------------------------------
 Full text of PR number 4642:
 
 Received: (qmail 15143 invoked by uid 2012); 24 Jun 1999 00:33:01 -0000
 Message-Id: <19...@hyperreal.org>
 Date: 24 Jun 1999 00:33:01 -0000
 From: James@hyperreal.org, C.Armstrong@hyperreal.org,
   Jr. <ja...@jamesarmstrong.com>
 Reply-To: james@jamesarmstrong.com
 To: apbugs@hyperreal.org
 Subject: Large memory growth, followed by occaisonal server failures
 X-Send-Pr-Version: 3.2
 
[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]