Sander Holthaus - Orange XL wrote: > I'm running Apache 2.0.52 and PHP 5.03 in a jailed (Virtual Private > Server) > FreeBSD 4.10 envirorement. PHP 5.03 is running as php_mod and was > installed > quite recently. Since then (better, since someone started using it) I've > been getting these errors in the httpd-error log: > > Allowed memory size of 8388608 bytes exhausted (tried to allocate 79 > bytes) > > And this one in the php-error log: > > [06-Feb-2005 17:25:50] PHP Fatal error: Allowed memory size of 8388608 > bytes exhausted (tried to allocate 6587593 bytes) in > xxx/xxx/xxx/xxx/xxx/xxx.php on line 53 Fix or disable that script. > I also see several thousands of notices in the PHP-error log within the > time-frame of a single second, plus diveded by zero, etc. Are they coming from the same script?... Again, fix or disable that script. > Of course, I asked the programmer to fix all of these issues.Among others, > there was a script that outputted a html-form with 2 columns, 100 rows > each > containing select-boxes with 100 full names (and those 100 names were the > same of every column/row in that form :-|). You're simply going to have to work with that programmer to get them to write better code, or not work with them (terminate their account). > But the problem is not so much that someone is using broken and the most > inefficient scripts, but more that they are crashing the entire box! That's definitely not good. But there is only so much you, and PHP, can do to stop a bad programmer from chewing up resources. > When these scripts are run, the box becomes totally unresponsive, > afterwards > all cgi and php request to Apache fail with a 500 error and sometimes the > whole box crashes completely, apparently from memory exhaustion. :-( > > It this a bug somewhere in PHP, Apache or FreeBSD? No. It's a bug in the script/program that causes the crash. > How can I protect myself against this? I can't manually check every > script, You can identify the culprit script, and disable it, and notify the client that they are violating their terms of service to run it again on a production server until it is debugged. Get them to install PHP on their own machine and develop on that. > and the memory and time limits in php.ini (20s for exe, 30s for input and > 8MB for mem) don't seem effective here. What are my options to make Apache > 2 > and PHP 5 full proof against such scripts? NOTHING is foolproof. Ever. You can change those numbers and be more harsh, but that will affect ALL users, not just the one who's bringing your box down. You would be far better off, for all your clients, to deal directly with the client who's causing the problems. Perhaps get them in touch with a good progammer, or up-sell them your services in fixing their scripts or... -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
