#28556 [Fbk->Opn]: PHP as CGI becomes a zombie when loaded too often
ID: 28556 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: It was the Debian 3.0 package, version 1.1.3-6.3 Previous Comments: [2005-03-02 23:21:28] [EMAIL PROTECTED] What libmm version do you have installed? (I can't reproduce this with latest stable CVS and libmm-1.3.1) [2005-03-01 19:23:06] floeff at arcor dot de I already tried without binfmt_misc, same problem. Regarding the snapshot: Unfortunately, I have no testing machine at the moment, and after removing that mm stuff, it works fine. I will get back to you if I have a testing machine again someday, but feel free to test it out yourself and ask whatever question you have. [2005-03-01 01:59:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And please try without using this binfmt_misc module to rule out THAT possible cause of this bug. [2005-02-06 14:27:36] floeff at arcor dot de Okay, here we go: ./configure --enable-safe-mode --with-mysql --enable-discard-path --with-exec-dir --enable-memory-limit --with-mm && make && make install cp php.ini-dist /usr/local/lib/php.ini echo ':PHP:E::php::/usr/local/bin/php:' > /proc/sys/fs/binfmt_misc/register echo ':PHP3:E::php3::/usr/local/bin/php:' > /proc/sys/fs/binfmt_misc/register echo ':PHP4:E::php4::/usr/local/bin/php:' > /proc/sys/fs/binfmt_misc/register Changes in php.ini: expose_php = Off disable_functions = phpinfo allow_url_fopen = Off In httpd.conf of Apache2: AddHandler cgi-script .cgi .pl .php .php3 .php4 [2005-02-06 06:57:15] [EMAIL PROTECTED] Come up with configuration that isn't "security threat" to you and put it here.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28556 -- Edit this bug report at http://bugs.php.net/?id=28556&edit=1
#28556 [Fbk->Opn]: PHP as CGI becomes a zombie when loaded too often
ID: 28556 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: I already tried without binfmt_misc, same problem. Regarding the snapshot: Unfortunately, I have no testing machine at the moment, and after removing that mm stuff, it works fine. I will get back to you if I have a testing machine again someday, but feel free to test it out yourself and ask whatever question you have. Previous Comments: [2005-03-01 01:59:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And please try without using this binfmt_misc module to rule out THAT possible cause of this bug. [2005-02-06 14:27:36] floeff at arcor dot de Okay, here we go: ./configure --enable-safe-mode --with-mysql --enable-discard-path --with-exec-dir --enable-memory-limit --with-mm && make && make install cp php.ini-dist /usr/local/lib/php.ini echo ':PHP:E::php::/usr/local/bin/php:' > /proc/sys/fs/binfmt_misc/register echo ':PHP3:E::php3::/usr/local/bin/php:' > /proc/sys/fs/binfmt_misc/register echo ':PHP4:E::php4::/usr/local/bin/php:' > /proc/sys/fs/binfmt_misc/register Changes in php.ini: expose_php = Off disable_functions = phpinfo allow_url_fopen = Off In httpd.conf of Apache2: AddHandler cgi-script .cgi .pl .php .php3 .php4 [2005-02-06 06:57:15] [EMAIL PROTECTED] Come up with configuration that isn't "security threat" to you and put it here.. ---------------- [2005-02-05 19:07:17] floeff at arcor dot de I don't post my (maybe security-related) configuration to the public, sorry. Any e-mail address I could mail it to? [2005-02-05 03:40:03] [EMAIL PROTECTED] DO NOT email anything to me!! Put any details needed to reproduce this bug here, via this url: http://bugs.php.net/bug.php?id=28556&edit=2 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28556 -- Edit this bug report at http://bugs.php.net/?id=28556&edit=1
#28556 [Fbk->Opn]: PHP as CGI becomes a zombie when loaded too often
ID: 28556 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: Okay, here we go: ./configure --enable-safe-mode --with-mysql --enable-discard-path --with-exec-dir --enable-memory-limit --with-mm && make && make install cp php.ini-dist /usr/local/lib/php.ini echo ':PHP:E::php::/usr/local/bin/php:' > /proc/sys/fs/binfmt_misc/register echo ':PHP3:E::php3::/usr/local/bin/php:' > /proc/sys/fs/binfmt_misc/register echo ':PHP4:E::php4::/usr/local/bin/php:' > /proc/sys/fs/binfmt_misc/register Changes in php.ini: expose_php = Off disable_functions = phpinfo allow_url_fopen = Off In httpd.conf of Apache2: AddHandler cgi-script .cgi .pl .php .php3 .php4 Previous Comments: [2005-02-06 06:57:15] [EMAIL PROTECTED] Come up with configuration that isn't "security threat" to you and put it here.. ---------------- [2005-02-05 19:07:17] floeff at arcor dot de I don't post my (maybe security-related) configuration to the public, sorry. Any e-mail address I could mail it to? [2005-02-05 03:40:03] [EMAIL PROTECTED] DO NOT email anything to me!! Put any details needed to reproduce this bug here, via this url: http://bugs.php.net/bug.php?id=28556&edit=2 ---------------- [2005-02-03 21:05:48] floeff at arcor dot de Unfortunately, I have no test system to try. If you want, I can mail you my documentation privately (via PM), so you can check it out. [2005-02-03 19:25:49] [EMAIL PROTECTED] And it still happens with latest CVS snapshot? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28556 -- Edit this bug report at http://bugs.php.net/?id=28556&edit=1
#28556 [Fbk->Opn]: PHP as CGI becomes a zombie when loaded too often
ID: 28556 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: I don't post my (maybe security-related) configuration to the public, sorry. Any e-mail address I could mail it to? Previous Comments: [2005-02-05 03:40:03] [EMAIL PROTECTED] DO NOT email anything to me!! Put any details needed to reproduce this bug here, via this url: http://bugs.php.net/bug.php?id=28556&edit=2 [2005-02-03 21:05:48] floeff at arcor dot de Unfortunately, I have no test system to try. If you want, I can mail you my documentation privately (via PM), so you can check it out. [2005-02-03 19:25:49] [EMAIL PROTECTED] And it still happens with latest CVS snapshot? [2005-02-03 08:46:42] floeff at arcor dot de Or was it --with-mm? [2005-02-03 04:04:22] [EMAIL PROTECTED] What --with-libmm do you mean? There is no such configure option in PHP.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28556 -- Edit this bug report at http://bugs.php.net/?id=28556&edit=1
#28556 [Fbk->Opn]: PHP as CGI becomes a zombie when loaded too often
ID: 28556 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: Unfortunately, I have no test system to try. If you want, I can mail you my documentation privately (via PM), so you can check it out. Previous Comments: [2005-02-03 19:25:49] [EMAIL PROTECTED] And it still happens with latest CVS snapshot? [2005-02-03 08:46:42] floeff at arcor dot de Or was it --with-mm? [2005-02-03 04:04:22] [EMAIL PROTECTED] What --with-libmm do you mean? There is no such configure option in PHP.. [2004-12-13 09:18:50] floeff at arcor dot de Sorry, seems I forgot to update this bug report. The problem disappears as soon as I do *NOT* compile with --with-libmm So it seem to be a libmm bug? [2004-07-08 17:58:36] floeff at arcor dot de I have tried on a lot of machines. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28556 -- Edit this bug report at http://bugs.php.net/?id=28556&edit=1
#28556 [Fbk->Opn]: PHP as CGI becomes a zombie when loaded too often
ID: 28556 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: Or was it --with-mm? Previous Comments: [2005-02-03 04:04:22] [EMAIL PROTECTED] What --with-libmm do you mean? There is no such configure option in PHP.. [2004-12-13 09:18:50] floeff at arcor dot de Sorry, seems I forgot to update this bug report. The problem disappears as soon as I do *NOT* compile with --with-libmm So it seem to be a libmm bug? [2004-12-13 01:06:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-07-08 17:58:36] floeff at arcor dot de I have tried on a lot of machines. [2004-07-08 13:02:00] [EMAIL PROTECTED] Have you tried on another machine? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28556 -- Edit this bug report at http://bugs.php.net/?id=28556&edit=1
#28556 [Opn]: PHP as CGI becomes a zombie when loaded too often
ID: 28556 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de Status: Open Bug Type: CGI related Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: Sorry, seems I forgot to update this bug report. The problem disappears as soon as I do *NOT* compile with --with-libmm So it seem to be a libmm bug? Previous Comments: [2004-12-13 09:18:50] floeff at arcor dot de Sorry, seems I forgot to update this bug report. The problem disappears as soon as I do *NOT* compile with --with-libmm So it seem to be a libmm bug? [2004-12-13 01:06:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-07-08 17:58:36] floeff at arcor dot de I have tried on a lot of machines. [2004-07-08 13:02:00] [EMAIL PROTECTED] Have you tried on another machine? [2004-06-24 18:18:03] trevor at verite dot com I have also experienced this problem, we have a nightly crontab that uses the CGI version of PHP to run a weekly import, every week we need to kill the script because even with a exit; command at the end it just keeps running and taking up more and more memory/processor time. I'm not sure if this is related but.. We're on a debian potato/apache 1.3/PHP 4.3.7 (Jun 7th Build). Any ideas? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28556 -- Edit this bug report at http://bugs.php.net/?id=28556&edit=1
#28556 [Fbk->Opn]: PHP as CGI becomes a zombie when loaded too often
ID: 28556 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: Sorry, seems I forgot to update this bug report. The problem disappears as soon as I do *NOT* compile with --with-libmm So it seem to be a libmm bug? Previous Comments: [2004-12-13 01:06:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-07-08 17:58:36] floeff at arcor dot de I have tried on a lot of machines. [2004-07-08 13:02:00] [EMAIL PROTECTED] Have you tried on another machine? [2004-06-24 18:18:03] trevor at verite dot com I have also experienced this problem, we have a nightly crontab that uses the CGI version of PHP to run a weekly import, every week we need to kill the script because even with a exit; command at the end it just keeps running and taking up more and more memory/processor time. I'm not sure if this is related but.. We're on a debian potato/apache 1.3/PHP 4.3.7 (Jun 7th Build). Any ideas? [2004-05-28 14:37:06] floeff at arcor dot de Description: Sorry for posting this again and again, but I still experience this problem and there seems to be no way for me to solve it. I've got confirmation from others that this problem is not only mine, so please take the time to read this. I've tried Apache 1.3 and 2.0, both on Linux 2.4. I've tried using suEXEC and not using suEXEC, and I even tried modules that stop script execution at a specific load average (tested with 1.00!) or number of processes (tested with 10!). But nothing seems to help in the following case: I run PHP as CGI because I don't want to have world-readable scripts and mod_perchild is not ready yet. When I do a hard reload - i.e. reloading the same script for about 10 seconds continously which should open quite a lot of scripts - I can crash the server. PHP-CGI-processes become zombies, I get a load average of about 90 (!) and it can take up to 30 minutes until the system responds again. This happens even with the simplest PHP scripts like a phpinfo call, but Perl scripts make absolutely no problem. The PHP developers say it's an Apache problem, the Apache developers say it's a PHP problem. So *PLEASE* take the time to review this one again - I'm helpless right now! :-( I know there must be a solution, because some providers run PHP as CGI without problems, but I don't know what it could be. :-( -- Edit this bug report at http://bugs.php.net/?id=28556&edit=1
#28556 [Fbk->Opn]: PHP as CGI becomes a zombie when loaded too often
ID: 28556 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: I have tried on a lot of machines. Previous Comments: [2004-07-08 13:02:00] [EMAIL PROTECTED] Have you tried on another machine? [2004-06-24 18:18:03] trevor at verite dot com I have also experienced this problem, we have a nightly crontab that uses the CGI version of PHP to run a weekly import, every week we need to kill the script because even with a exit; command at the end it just keeps running and taking up more and more memory/processor time. I'm not sure if this is related but.. We're on a debian potato/apache 1.3/PHP 4.3.7 (Jun 7th Build). Any ideas? [2004-05-28 14:37:06] floeff at arcor dot de Description: Sorry for posting this again and again, but I still experience this problem and there seems to be no way for me to solve it. I've got confirmation from others that this problem is not only mine, so please take the time to read this. I've tried Apache 1.3 and 2.0, both on Linux 2.4. I've tried using suEXEC and not using suEXEC, and I even tried modules that stop script execution at a specific load average (tested with 1.00!) or number of processes (tested with 10!). But nothing seems to help in the following case: I run PHP as CGI because I don't want to have world-readable scripts and mod_perchild is not ready yet. When I do a hard reload - i.e. reloading the same script for about 10 seconds continously which should open quite a lot of scripts - I can crash the server. PHP-CGI-processes become zombies, I get a load average of about 90 (!) and it can take up to 30 minutes until the system responds again. This happens even with the simplest PHP scripts like a phpinfo call, but Perl scripts make absolutely no problem. The PHP developers say it's an Apache problem, the Apache developers say it's a PHP problem. So *PLEASE* take the time to review this one again - I'm helpless right now! :-( I know there must be a solution, because some providers run PHP as CGI without problems, but I don't know what it could be. :-( -- Edit this bug report at http://bugs.php.net/?id=28556&edit=1
#28556 [NEW]: PHP as CGI becomes a zombie when loaded too often
From: floeff at arcor dot de Operating system: Linux 2.4 PHP version: 4.3.6 PHP Bug Type: Reproducible crash Bug description: PHP as CGI becomes a zombie when loaded too often Description: Sorry for posting this again and again, but I still experience this problem and there seems to be no way for me to solve it. I've got confirmation from others that this problem is not only mine, so please take the time to read this. I've tried Apache 1.3 and 2.0, both on Linux 2.4. I've tried using suEXEC and not using suEXEC, and I even tried modules that stop script execution at a specific load average (tested with 1.00!) or number of processes (tested with 10!). But nothing seems to help in the following case: I run PHP as CGI because I don't want to have world-readable scripts and mod_perchild is not ready yet. When I do a hard reload - i.e. reloading the same script for about 10 seconds continously which should open quite a lot of scripts - I can crash the server. PHP-CGI-processes become zombies, I get a load average of about 90 (!) and it can take up to 30 minutes until the system responds again. This happens even with the simplest PHP scripts like a phpinfo call, but Perl scripts make absolutely no problem. The PHP developers say it's an Apache problem, the Apache developers say it's a PHP problem. So *PLEASE* take the time to review this one again - I'm helpless right now! :-( I know there must be a solution, because some providers run PHP as CGI without problems, but I don't know what it could be. :-( -- Edit bug report at http://bugs.php.net/?id=28556&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28556&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28556&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28556&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28556&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28556&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28556&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28556&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28556&r=support Expected behavior: http://bugs.php.net/fix.php?id=28556&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28556&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28556&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28556&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28556&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28556&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28556&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28556&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28556&r=float
#28550 [WFx]: limit number of simultaneous processes
ID: 28550 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de Status: Wont fix Bug Type: Feature/Change Request Operating System: Linux 2.4 PHP Version: 4.3.6 New Comment: I did not find any way to limit this in Apache, and this problem really worries me. So if you know anything, PLEASE let me know! Previous Comments: [2004-05-27 23:42:09] [EMAIL PROTECTED] That's already handled (appriately so) in the webserver. Check your webservers documentation for how to implement. [2004-05-27 22:52:46] floeff at arcor dot de Description: I would like to see a feature to limit the number of simultaneous PHP-as-CGI processes, maybe per user. -- Edit this bug report at http://bugs.php.net/?id=28550&edit=1
#28550 [NEW]: limit number of simultaneous processes
From: floeff at arcor dot de Operating system: Linux 2.4 PHP version: 4.3.6 PHP Bug Type: Feature/Change Request Bug description: limit number of simultaneous processes Description: I would like to see a feature to limit the number of simultaneous PHP-as-CGI processes, maybe per user. -- Edit bug report at http://bugs.php.net/?id=28550&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28550&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28550&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28550&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28550&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28550&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28550&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28550&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28550&r=support Expected behavior: http://bugs.php.net/fix.php?id=28550&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28550&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28550&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28550&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28550&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28550&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28550&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28550&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28550&r=float
#28457 [WFx]: PHP should be able to check certain conditions before invoking the script
ID: 28457 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de Status: Wont fix Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.3.6 New Comment: Having mod_php can be a security risk, too. Previous Comments: [2004-05-20 20:42:43] [EMAIL PROTECTED] Having a windows box on the internet is a security risk too, and people still do it even if they are warned. [2004-05-20 19:47:03] floeff at arcor dot de You should at least provide some tips for stopping these problems, as I consider this a security risk. [2004-05-20 18:55:03] [EMAIL PROTECTED] This is not something that PHP should implement, as it's not PHPs job to make sure your system "doesn't overload". It's an operating systems feature, or at most done by the webserver. ---- [2004-05-20 17:14:22] floeff at arcor dot de Description: PHP should be able to check certain conditions before invoking the script. I would like to be able to check - number of already running PHP(-as-CGI) instances - load average of the system If some user-definable values are exceed, PHP should NOT invoke the required script, but instead printing out a "System overload, please try again later" message. -- Edit this bug report at http://bugs.php.net/?id=28457&edit=1
#28457 [WFx]: PHP should be able to check certain conditions before invoking the script
ID: 28457 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de Status: Wont fix Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.3.6 New Comment: You should at least provide some tips for stopping these problems, as I consider this a security risk. Previous Comments: [2004-05-20 18:55:03] [EMAIL PROTECTED] This is not something that PHP should implement, as it's not PHPs job to make sure your system "doesn't overload". It's an operating systems feature, or at most done by the webserver. ---- [2004-05-20 17:14:22] floeff at arcor dot de Description: PHP should be able to check certain conditions before invoking the script. I would like to be able to check - number of already running PHP(-as-CGI) instances - load average of the system If some user-definable values are exceed, PHP should NOT invoke the required script, but instead printing out a "System overload, please try again later" message. -- Edit this bug report at http://bugs.php.net/?id=28457&edit=1
#28457 [NEW]: PHP should be able to check certain conditions before invoking the script
From: floeff at arcor dot de Operating system: Linux PHP version: 4.3.6 PHP Bug Type: Feature/Change Request Bug description: PHP should be able to check certain conditions before invoking the script Description: PHP should be able to check certain conditions before invoking the script. I would like to be able to check - number of already running PHP(-as-CGI) instances - load average of the system If some user-definable values are exceed, PHP should NOT invoke the required script, but instead printing out a "System overload, please try again later" message. -- Edit bug report at http://bugs.php.net/?id=28457&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28457&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28457&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28457&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28457&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28457&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28457&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28457&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28457&r=support Expected behavior: http://bugs.php.net/fix.php?id=28457&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28457&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28457&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28457&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28457&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28457&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28457&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28457&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28457&r=float
#28238 [NEW]: --enable-discard-path prevents PHP from being run as CGI with Apache
From: floeff at arcor dot de Operating system: Linux PHP version: 4.3.6 PHP Bug Type: CGI related Bug description: --enable-discard-path prevents PHP from being run as CGI with Apache Description: It seems that --enable-discard-path prevents PHP from being run as CGI with Apache. My configure options are as follows: ./configure --enable-safe-mode --with-mm --with-mysql --enable-discard-path --with-exec-dir --enable-memory-limit --enable-force-cgi-redirect PHP has been enabled in Apache with these settings in httpd.conf: Order allow,deny Allow from all ScriptAlias /.php-script/ /usr/local/bin/ AddHandler php-script .php Action php-script /.php-script/php This does not work. I receive parse errors for ASCII characters, it seems that no PHP script is being parsed, but some binary data. As soon as I remove --enable-discard-path it works fine. I run Apache 2.0.49. Seems to be related to Bug #18371. Reproduce code: --- or any other PHP code. Expected result: Parse error. Actual result: -- Correct PHP output. -- Edit bug report at http://bugs.php.net/?id=28238&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28238&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28238&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28238&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28238&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28238&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28238&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28238&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28238&r=support Expected behavior: http://bugs.php.net/fix.php?id=28238&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28238&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28238&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28238&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28238&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28238&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28238&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28238&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28238&r=float
#28065 [Bgs]: resource limits do not work
ID: 28065 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de Status: Bogus Bug Type: Reproducible crash Operating System: Linux 2.4.26 PHP Version: 4.3.6 New Comment: > Don't run PHP as CGI I need to run PHP as a user, so there only seems to be the CGI method. Does memory limitation not work for CGI? Previous Comments: [2004-04-22 15:11:51] floeff at arcor dot de > Don't run PHP as CGI I need to run PHP as a user, so there only seems to be the CGI method. Does memory limitation not work for CGI? [2004-04-22 09:29:21] [EMAIL PROTECTED] 1. Don't run Apache 2 2. Don't run PHP as CGI Do use apache 1.3 with the apache SAPI and this works fine; apache 2 is NOT ready for production. ---- [2004-04-21 21:36:55] floeff at arcor dot de I checked some more things, here some more results: - On my test machine, I've set MaxClients in httpd.conf to 20 and I couldn't kill the machine anymore. This is only a workaround, as it knocks out a lot of users on higher load machines, but at least it shows that MaxClients works for that. - When a "normal access" (i.e. not my "attack") accesses a PHP script, the PHP parser is only shown during the run of the script, checked with ps auxw | grep php. However, when I "attack", it runs for quite a while several times. It does seem to use the 300 seconds timeout, as I lowered this to 10 seconds, and the scripts got killed with "(70007)The timeout specified has expired: ap_content_length_filter: apr_bucket_read() failed". However, it does not help to lower it, the load rises even more. Had about 97 (!) some seconds ago :-( "killall php" or "killall -9 php" doesn't help. However, shutting down Apache brings down the PHP interpreters, so I think that Apache just "forgets" about the running instances when it is flooded and cannot handle them anymore. Do you have any idea? Do you need more information? -------- [2004-04-20 19:05:25] floeff at arcor dot de If PHP does not terminate after the set amount of time, then for me it is a bug. Why shouldn't it be one? [2004-04-19 23:23:34] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28065 -- Edit this bug report at http://bugs.php.net/?id=28065&edit=1
#28065 [Bgs]: resource limits do not work
ID: 28065 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de Status: Bogus Bug Type: Reproducible crash Operating System: Linux 2.4.26 PHP Version: 4.3.6 New Comment: > Don't run PHP as CGI I need to run PHP as a user, so there only seems to be the CGI method. Does memory limitation not work for CGI? Previous Comments: [2004-04-22 09:29:21] [EMAIL PROTECTED] 1. Don't run Apache 2 2. Don't run PHP as CGI Do use apache 1.3 with the apache SAPI and this works fine; apache 2 is NOT ready for production. [2004-04-21 21:36:55] floeff at arcor dot de I checked some more things, here some more results: - On my test machine, I've set MaxClients in httpd.conf to 20 and I couldn't kill the machine anymore. This is only a workaround, as it knocks out a lot of users on higher load machines, but at least it shows that MaxClients works for that. - When a "normal access" (i.e. not my "attack") accesses a PHP script, the PHP parser is only shown during the run of the script, checked with ps auxw | grep php. However, when I "attack", it runs for quite a while several times. It does seem to use the 300 seconds timeout, as I lowered this to 10 seconds, and the scripts got killed with "(70007)The timeout specified has expired: ap_content_length_filter: apr_bucket_read() failed". However, it does not help to lower it, the load rises even more. Had about 97 (!) some seconds ago :-( "killall php" or "killall -9 php" doesn't help. However, shutting down Apache brings down the PHP interpreters, so I think that Apache just "forgets" about the running instances when it is flooded and cannot handle them anymore. Do you have any idea? Do you need more information? ------------ [2004-04-20 19:05:25] floeff at arcor dot de If PHP does not terminate after the set amount of time, then for me it is a bug. Why shouldn't it be one? [2004-04-19 23:23:34] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . ------------ [2004-04-19 19:49:35] floeff at arcor dot de Description: Maybe I misunderstand something, but for me it seems that the resource limits do not work. In my php.ini, I set max_execution_time = 10 max_input_time = 10 which - to my understanding - should limit executing time for scripts to 10 seconds. I have PHP running as CGI with Apache 2.0.49 on Linux 2.4.26 here, and with a hughe PHP file involving some diagram creation, I can kill the machine if I re-load the script for five seconds continuously. It soaks up all my memory and runs for nearly a minute. What could be wrong in here? If you need more information, please let me know. Thanks! -- Edit this bug report at http://bugs.php.net/?id=28065&edit=1
#28065 [Bgs->Opn]: resource limits do not work
ID: 28065 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Bogus +Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.26 PHP Version: 4.3.6 New Comment: I checked some more things, here some more results: - On my test machine, I've set MaxClients in httpd.conf to 20 and I couldn't kill the machine anymore. This is only a workaround, as it knocks out a lot of users on higher load machines, but at least it shows that MaxClients works for that. - When a "normal access" (i.e. not my "attack") accesses a PHP script, the PHP parser is only shown during the run of the script, checked with ps auxw | grep php. However, when I "attack", it runs for quite a while several times. It does seem to use the 300 seconds timeout, as I lowered this to 10 seconds, and the scripts got killed with "(70007)The timeout specified has expired: ap_content_length_filter: apr_bucket_read() failed". However, it does not help to lower it, the load rises even more. Had about 97 (!) some seconds ago :-( "killall php" or "killall -9 php" doesn't help. However, shutting down Apache brings down the PHP interpreters, so I think that Apache just "forgets" about the running instances when it is flooded and cannot handle them anymore. Do you have any idea? Do you need more information? Previous Comments: -------------------- [2004-04-20 19:05:25] floeff at arcor dot de If PHP does not terminate after the set amount of time, then for me it is a bug. Why shouldn't it be one? [2004-04-19 23:23:34] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . ---------------- [2004-04-19 19:49:35] floeff at arcor dot de Description: Maybe I misunderstand something, but for me it seems that the resource limits do not work. In my php.ini, I set max_execution_time = 10 max_input_time = 10 which - to my understanding - should limit executing time for scripts to 10 seconds. I have PHP running as CGI with Apache 2.0.49 on Linux 2.4.26 here, and with a hughe PHP file involving some diagram creation, I can kill the machine if I re-load the script for five seconds continuously. It soaks up all my memory and runs for nearly a minute. What could be wrong in here? If you need more information, please let me know. Thanks! -- Edit this bug report at http://bugs.php.net/?id=28065&edit=1
#28065 [Bgs]: resource limits do not work
ID: 28065 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de Status: Bogus Bug Type: Reproducible crash Operating System: Linux 2.4.26 PHP Version: 4.3.6 New Comment: If PHP does not terminate after the set amount of time, then for me it is a bug. Why shouldn't it be one? Previous Comments: [2004-04-19 23:23:34] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . [2004-04-19 19:49:35] floeff at arcor dot de Description: Maybe I misunderstand something, but for me it seems that the resource limits do not work. In my php.ini, I set max_execution_time = 10 max_input_time = 10 which - to my understanding - should limit executing time for scripts to 10 seconds. I have PHP running as CGI with Apache 2.0.49 on Linux 2.4.26 here, and with a hughe PHP file involving some diagram creation, I can kill the machine if I re-load the script for five seconds continuously. It soaks up all my memory and runs for nearly a minute. What could be wrong in here? If you need more information, please let me know. Thanks! -- Edit this bug report at http://bugs.php.net/?id=28065&edit=1
#28065 [NEW]: resource limits do not work
From: floeff at arcor dot de Operating system: Linux 2.4.26 PHP version: 4.3.6 PHP Bug Type: Reproducible crash Bug description: resource limits do not work Description: Maybe I misunderstand something, but for me it seems that the resource limits do not work. In my php.ini, I set max_execution_time = 10 max_input_time = 10 which - to my understanding - should limit executing time for scripts to 10 seconds. I have PHP running as CGI with Apache 2.0.49 on Linux 2.4.26 here, and with a hughe PHP file involving some diagram creation, I can kill the machine if I re-load the script for five seconds continuously. It soaks up all my memory and runs for nearly a minute. What could be wrong in here? If you need more information, please let me know. Thanks! -- Edit bug report at http://bugs.php.net/?id=28065&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28065&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28065&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28065&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28065&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28065&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28065&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28065&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28065&r=support Expected behavior: http://bugs.php.net/fix.php?id=28065&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28065&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28065&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28065&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28065&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28065&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28065&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28065&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28065&r=float
#28021 [Fbk->Opn]: user and group of the tar archived files should be set to nobody:nogroup
ID: 28021 User updated by: floeff at arcor dot de Reported By: floeff at arcor dot de -Status: Feedback +Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.3.6RC3 New Comment: http://www.php.net/get/php-4.3.6.tar.bz2/from/a/mirror and http://www.php.net/get/php-4.3.6.tar.gz/from/a/mirror Previous Comments: [2004-04-16 15:08:47] [EMAIL PROTECTED] what tar file? [2004-04-16 05:53:28] floeff at arcor dot de Description: The user and group of the tar archived files should be set to nobody:nogroup. Right now they are 1003:1003, which can cause quota warning error messages (and more!) on some systems where this user exist. -- Edit this bug report at http://bugs.php.net/?id=28021&edit=1
#28021 [NEW]: user and group of the tar archived files should be set to nobody:nogroup
From: floeff at arcor dot de Operating system: Linux PHP version: 4.3.6RC3 PHP Bug Type: Unknown/Other Function Bug description: user and group of the tar archived files should be set to nobody:nogroup Description: The user and group of the tar archived files should be set to nobody:nogroup. Right now they are 1003:1003, which can cause quota warning error messages (and more!) on some systems where this user exist. -- Edit bug report at http://bugs.php.net/?id=28021&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28021&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28021&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28021&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28021&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28021&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28021&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28021&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28021&r=support Expected behavior: http://bugs.php.net/fix.php?id=28021&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28021&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28021&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28021&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28021&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28021&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28021&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28021&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28021&r=float
