Bug 1623

Summary:	kill -HUP `cat /var/run/httpsd.pid` aggrevates memory leak
Product:	[Retired] Red Hat Secure Web Server	Reporter:	cdent
Component:	mod_perl	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	2.0
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-01-13 04:46:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description cdent 1999-03-19 06:56:08 UTC

It appears that the mod_perl shipped with secureweb
has a memory leak when configured as a DSO that can
be demostrated on a server that has the mod_perl
module included but doesn't actually call any perl
by hupping the server while watching the process
size. The mod_perl version grows considerably faster
than the non-mod_perl version.

I've tried a few different combinations:

perl 5004_01, perl 5004_04, mod_perl 1.16, 1.16_02,
1.18

This is all with redhat 4.2

I've read that it may be better to make mod_perl not
be a DSO but have it in the binary instead. Some of
the folks on the mod_perl list claim that helps.
This is inconvenient for you folks but perhaps you
would consider shipping the rpm either with two
binaries or in two flavors?

Comment 1 Preston Brown 1999-05-17 14:17:59 UTC

mod_perl 1.19 still has this memory leak.  I am discussing things with
the developers.

Comment 2 jacob 1999-08-03 19:03:59 UTC

I'm seeing major problems with busy servers without using mod_perl,
too.  My httpsd processes are growing to over 50 megs total size
pretty quickly if they see significant load.

The one test server I had with mod_perl included grew to over 150 megs
without any load at all.  Any progress on this?

Comment 3 Preston Brown 2000-01-13 04:46:59 UTC

the concensus among mod_perl people seems to be to restart the server
periodically in a cron job if you are experiencing memory leaks.  While the
problem may be fixed in a better way down the road, this is the current
solution, and while sub-optimal, it works.