Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 56898

Summary: httpd threads go zombie with large PHP LDAP queries
Product: [Retired] Red Hat Linux Reporter: Darren Gamble <darren.gamble>
Component: phpAssignee: Phil Copeland <copeland>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-12-07 23:57:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Darren Gamble 2001-11-29 19:46:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
After querying an LDAP database for a large number of entries with a PHP 
script, the httpd process does not terminate, holding onto a large amount 
of memory (in this case, about 110MB).  Repeated calls to the program 
zombify additional processes and use more memory, until none are available.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Start apache w/ php, ldap server.
2. Run PHP script which queries server for objectclass=*
3. Note that process doesn't quit and can't be killed, other than kill -9.
4. Repeat process, note that server stops serving requests.
	

Actual Results:  The httpd processes used most of the memory on the 
machine and stopped serving requests.  They could not be kill-ed unless 
they were kill -9'ed.  Using /etc/init.d/httpd stop will work, but only if 
it is run twice (both will return "OK", however).  After the processes are 
finally removed, the memory they used become available.

Expected Results:  The process should have terminated normally.

Additional info:

Running php-4.0.6-7 under apache-1.3.20-16, installed with Redhat 7.2 RPMs 
(default configuration).  The LDAP server has about 8k entries with an 
ldif that is around 8MB in size.  This may not be restricted to LDAP and 
may instead just be a problem with PHP using a large amount of memory; the 
httpd process uses over 100MB of memory when the query is done.  Smaller 
queries on the server do not produce this problem.

Sample Apache error log entry when an attempt to shut it down is made:

[warn] child process 6179 still did not exit, sending a SIGTERM


Code snippet is included for verboseness:

<?php

echo"
<HTML>
<HEAD>
  <META HTTP-EQUIV=\"expires\" CONTENT=\"0\">
</HEAD>
<BODY BACKGROUND='/images/blue_sidebar.jpg' BGPROPERTIES='fixed'>
<LINK rel='stylesheet' href='/stylesheets/main.css' 
src='/stylesheets/main.css'>
<BR>
";

$query = "objectclass=*";

echo "<H1>Raw LDAP Test</H2>\n";
echo "<OL>";
echo "<LI>Starting query \"".$query."\"...<BR>";

$start_time = posix_times();
// Connect and bind

$ldap_link_id = @ldap_connect("localhost");
$ldap_bind_id = ldap_bind
($ldap_link_id,"cn=Manager,o=Shawtest,dc=shaw,dc=ca","d8bxl3");

// Actually do the query

$search_session = ldap_search
($ldap_link_id, "o=Shawtest,dc=shaw,dc=ca" , "$query" );

if ( $search_session ) {
  $search_results = ldap_get_entries($ldap_link_id,$search_session);
} else {
  die("Test failed. ");
}

$end_time = posix_times();
ldap_free_result($search_session);
$elapsed_time = ($end_time['ticks'] - $start_time['ticks']) / 100.0;
echo "Done.  Elapsed time: <B>".$elapsed_time."s</B>. <B>".$search_results
['count']."</B> results returned.<BR><BR></LI>\n";
$search_results = array();

ldap_unbind($ldap_link_id);

echo "</OL><P>Test completed.</P>

</BODY>
</HTML>
";
?>

Comment 1 Phil Copeland 2002-03-04 21:06:26 UTC
Humm I may have something odd going on at my end, but I'm trying your script
with 4.1.2
Should be in the rawhide tree tonight, I strongly suggest rebuilding it from the
SRPM as theres no guarentee that the libs that are constanly moving in rawhide
will reflect your own setup.

Should be in rawhide by 03:00est tonight 

Phil
=--=