Bug #14333 Updated: Apache processes consume all CPU

ID: 14333 User updated by: tauren@servlets.net Reported By: tauren@servlets.net 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] sniper@php.net 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] tauren@servlets.net 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] tauren@servlets.net 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