ID: 14333
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Apache related
Operating System: RH 6.2 SMP
PHP Version: 4.0.6
New Comment:

It's interesting that you aren't experiencing the same problems.  I wonder why I (and 
several others) are having trouble.  Here's the info you've requested.

Kernel/glibc version: 
  Red Hat Linux release 6.2 (Zoot)
  Kernel 2.2.14-5.0smp on a 2-processor i686

Apache version:
  Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6

Please note that I'm not manually building Apache with PHP.  I've built Apache 
manually many times, but by the time I wanted to use PHP, I was using ApacheToolbox 
(ATB) to build my Apache distributions.  ATB is a script that eases the download and 
configuration of Apache with many supported modules.  It really simplifies the 
building of Apache+ModSSL+PHP+OtherStuff.  It can be downloaded at 
www.apachetoolbox.com.  Below is the PHP configure line that it generates and lets me 
edit before PHP is configured.

PHP configure line:
  CPPFLAGS=-I/usr/local/include
  LDFLAGS=-L/usr/local/lib
  ./configure --prefix=/usr/local \
  --with-apache=/root/atb/Apachetoolbox-1.5.45/apache_1.3.22 \
  --enable-exif \
  --enable-track-vars \
  --with-calendar=shared \
  --enable-safe-mode \
  --enable-magic-quotes \
  --enable-trans-sid \
  --enable-wddx \
  --enable-ftp \
  --with-mysql \
  --with-ldap \

ATB then generates this Apache configuration line and lets me edit it before 
configuring Apache:

export CFLAGS=""
export LIBS=""
export INCLUDES=""
./configure --prefix=/usr/local/apache \
--enable-suexec \
--suexec-caller=nobody \
--enable-module=so \
--enable-module=access \
--disable-module=auth_db \
--disable-module=digest \
--enable-module=imap \
--enable-module=mime \
--enable-module=setenvif \
--disable-module=usertrack \
--enable-module=auth \
--disable-module=cern_meta \
--disable-module=expires \
--enable-module=log_config \
--disable-module=proxy \
--disable-module=vhost_alias \
--disable-module=auth_anon \
--enable-module=cgi \
--disable-module=headers \
--disable-module=log_referer \
--enable-module=rewrite \
--enable-module=userdir \
--enable-module=asis \
--enable-module=autoindex \
--disable-module=example \
--disable-module=log_agent \
--enable-module=negotiation \
--enable-module=status \
--enable-module=actions \
--disable-module=auth_dbm \
--enable-module=dir \
--enable-module=include \
--disable-module=mime_magic \
--disable-module=unique_id \
--enable-module=alias \
--disable-module=auth_digest \
--enable-module=env \
--disable-module=info \
--disable-module=mmap_static \
--disable-module=speling \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \

A couple other things...  The MM library (mm-1.1.3) is being used with Apache.  I've 
been using this with my Apache builds for years and it hasn't caused any trouble 
before.  Also, Apache is built as a static binary with DSO support.  PHP is built into 
it, not as a DSO.

I'll give PHP 4.1.0RC5 a try and let you know what happens.

Also, yes I am using ./apachectl stop and start, not restart or graceful.  Doesn't 
hurt to be thorough with your questions...

Thanks for your help!
Tauren




Previous Comments:
------------------------------------------------------------------------

[2001-12-03 20:56:04] [EMAIL PROTECTED]

I'm also running PHP / Apache in a SMP machine but I never
have noticed anything like this. Some things we need to know about
your system:

- Kernel/glibc version
- Apache version 
- PHP configure line

And you should also try with PHP 4.1.0RC5:

http://www.php.net/~zeev/php-4.1.0RC5.tar.gz

--Jani

p.s. This might sound stupid but did you do './apachectl stop ; ./apachectl start' or 
did you use './apachectl restart' ?


------------------------------------------------------------------------

[2001-12-03 19:35:22] [EMAIL PROTECTED]

Actually, there is a sample PHP script installed on the server in several user 
directories.  But this is the ONLY file with a *.php* extension within our web root 
directories. It is called "hello.php3" and it looks like this:

<html><head><title>PHP Test</title></head>
<body>
<?php echo "Hello World<P>"; ?>
</body></html>

I really don't think this script is being run.  I don't think that any script is being 
run to cause the problem.

Thanks,
Tauren


------------------------------------------------------------------------

[2001-12-03 19:21:39] [EMAIL PROTECTED]

I've been experiencing the exact same problem that is described in bug #14290 and 
#8446 for quite some time now but did not know which Apache module was causing it.  Up 
until now, I've had a cron job that simply kills off (with a -9) any httpd processes 
that are using 99% or more cpu time.

Today I've been trying to track down what exactly is causing the problem.  I've 
eliminated all extra Apache modules and did not experience the problem.  When I added 
PHP back in, the problem started immediately.  Within one minute of starting Apache 
back up, the high-CPU processes started appearing again.

The Apache "server-status" didn't indicate that ANY php script had been hit.  The 
processes just start going out of control after some time.  In fact, there isn't even 
a single *.php* file on the server.  I really don't think this is happening because of 
a PHP script being run.

I'm currently testing this out on a Red Hat 6.2 Linux (SMP) box with dual CPUs.  From 
the sound of things in the other bug reports (#14290 and #8446), the problem only 
seems to be happening on SMP servers.  I did not compile with any extra PHP modules 
except for the core PHP 4.0.6.

I haven't really done a lot with PHP, so I'm not sure how to help debug this problem.  
But I do want a stable Apache environment with PHP support for my hosting customers.  
If there is anything I can do to help debug things, please let me know.  

I've read the page on using gdb, but I'm think this is a different kind of situation.  
Apache isn't crashing, but certain processes are going "out-of-control".  Is there a 
way to get a backtrace of a particular process while it is still running?

Until this problem can be resolved, I'm going to have to remove PHP from my servers.  
I really don't want to have to do this, but the instabilities are becoming too much to 
handle and very hard to explain to our customers.

Please let me know what I can do to help debug and solve this problem.  

Thanks!
Tauren



------------------------------------------------------------------------



Edit this bug report at http://bugs.php.net/?id=14333&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to