[PHP] Notices flooding logs with fastcgi
Hello everybody, I have chosen this list because my problem is related to one particular style of php installation. At least I think so. I'm running php 5.2.11 and plesk 9.2.3, php through fastCGI. My problem is that, since error_log is unset, php passes on any errors to the webserver (-handler). This fills up my logs with hundreds of MBytes of Notices every day, even though error_reporting is set to 6135 (notices shouldn't be logged). So error_reporting appears to be ignored when error_log is unset and php is run through fastcgi. Any idea how I can fix that? I unfortunately can't change error_log to the appropriate path, because the fastcgi user doesn't have access to the log directory... Here is an example log: [Mon Oct 26 00:57:52 2009] [warn] mod_fcgid: stderr: PHP Notice: Undefined offset: 1 in /srv/www/vhosts//httpdocs/ x3/inc/shopstat_functions.inc.php on line 82 Thanks so much in advance, -- Cheers, Max GNU/Linux - User #477672 PGP: 0x6C29B594
Re: [PHP] Notices flooding logs with fastcgi
2010/1/18 Ashley Sheridan a...@ashleysheridan.co.uk On Mon, 2010-01-18 at 12:20 +, Max Zimmermann wrote: Hello everybody, I have chosen this list because my problem is related to one particular style of php installation. At least I think so. I'm running php 5.2.11 and plesk 9.2.3, php through fastCGI. My problem is that, since error_log is unset, php passes on any errors to the webserver (-handler). This fills up my logs with hundreds of MBytes of Notices every day, even though error_reporting is set to 6135 (notices shouldn't be logged). So error_reporting appears to be ignored when error_log is unset and php is run through fastcgi. Any idea how I can fix that? I unfortunately can't change error_log to the appropriate path, because the fastcgi user doesn't have access to the log directory... Here is an example log: [Mon Oct 26 00:57:52 2009] [warn] mod_fcgid: stderr: PHP Notice: Undefined offset: 1 in /srv/www/vhosts//httpdocs/ x3/inc/shopstat_functions.inc.php on line 82 Thanks so much in advance, -- Cheers, Max GNU/Linux - User #477672 PGP: 0x6C29B594 I believe that the reporting level is only used for errors displayed in the browser window, not to the ones that are logged. If you're having your error logs fill up with errors, this isn't an issue with PHP but the coder! It is obviously more than a few errors, unless your website has millions of visitors each day triggering the same error, but which is more likely a scenario?! I'd advise fixing those errors, even the warnings, as warnings are often a prelude to a logic problem somewhere in the code. Thanks, Ash http://www.ashleysheridan.co.uk Hey Ash, thanks for your reply. I know this is a coding issue, and xt:commerce always produces loads of notices. That said, I think the error_reporting setting does apply to logging when mod_php is used. I could be wrong though. But even fixing the whole of xt:commerce code to be notice free (which would be rediculously much work) doesn't solve the problem. Whenever anyone is installing something new on his website lying on this server, I'm gonna have the same problem again. I can't spend my whole time basically reviewing code that someone runs on the server... I think that's understandable ;) So I'm afraid I'm gonna need some other ideas :( Thanks again, Max
Re: [PHP] Notices flooding logs with fastcgi
2010/1/18 Richard Quadling rquadl...@googlemail.com 2010/1/18 Max Zimmermann maxzimmerm...@googlemail.com: 2010/1/18 Ashley Sheridan a...@ashleysheridan.co.uk On Mon, 2010-01-18 at 12:20 +, Max Zimmermann wrote: Hello everybody, I have chosen this list because my problem is related to one particular style of php installation. At least I think so. I'm running php 5.2.11 and plesk 9.2.3, php through fastCGI. My problem is that, since error_log is unset, php passes on any errors to the webserver (-handler). This fills up my logs with hundreds of MBytes of Notices every day, even though error_reporting is set to 6135 (notices shouldn't be logged). So error_reporting appears to be ignored when error_log is unset and php is run through fastcgi. Any idea how I can fix that? I unfortunately can't change error_log to the appropriate path, because the fastcgi user doesn't have access to the log directory... Here is an example log: [Mon Oct 26 00:57:52 2009] [warn] mod_fcgid: stderr: PHP Notice: Undefined offset: 1 in /srv/www/vhosts//httpdocs/ x3/inc/shopstat_functions.inc.php on line 82 Thanks so much in advance, -- Cheers, Max GNU/Linux - User #477672 PGP: 0x6C29B594 I believe that the reporting level is only used for errors displayed in the browser window, not to the ones that are logged. If you're having your error logs fill up with errors, this isn't an issue with PHP but the coder! It is obviously more than a few errors, unless your website has millions of visitors each day triggering the same error, but which is more likely a scenario?! I'd advise fixing those errors, even the warnings, as warnings are often a prelude to a logic problem somewhere in the code. Thanks, Ash http://www.ashleysheridan.co.uk Hey Ash, thanks for your reply. I know this is a coding issue, and xt:commerce always produces loads of notices. That said, I think the error_reporting setting does apply to logging when mod_php is used. I could be wrong though. But even fixing the whole of xt:commerce code to be notice free (which would be rediculously much work) doesn't solve the problem. Whenever anyone is installing something new on his website lying on this server, I'm gonna have the same problem again. I can't spend my whole time basically reviewing code that someone runs on the server... I think that's understandable ;) So I'm afraid I'm gonna need some other ideas :( Thanks again, Max Don't log the errors! Let them go to php's normal error log. If you can have a per-site setup, then log them per site and pass them to the coder/owner to fix. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling Hey Richard, thanks for you reply. Yes, that was what I was thinking about. And after a bit of thinking, this is what I'm going to do. Everything else seems pointless :) Thanks for the tip! Max
Re: [PHP] Notices flooding logs with fastcgi
2010/1/18 Robert Cummings rob...@interjinn.com Ashley Sheridan wrote: On Mon, 2010-01-18 at 12:20 +, Max Zimmermann wrote: Hello everybody, I have chosen this list because my problem is related to one particular style of php installation. At least I think so. I'm running php 5.2.11 and plesk 9.2.3, php through fastCGI. My problem is that, since error_log is unset, php passes on any errors to the webserver (-handler). This fills up my logs with hundreds of MBytes of Notices every day, even though error_reporting is set to 6135 (notices shouldn't be logged). So error_reporting appears to be ignored when error_log is unset and php is run through fastcgi. Any idea how I can fix that? I unfortunately can't change error_log to the appropriate path, because the fastcgi user doesn't have access to the log directory... Here is an example log: [Mon Oct 26 00:57:52 2009] [warn] mod_fcgid: stderr: PHP Notice: Undefined offset: 1 in /srv/www/vhosts//httpdocs/ x3/inc/shopstat_functions.inc.php on line 82 Thanks so much in advance, -- Cheers, Max GNU/Linux - User #477672 PGP: 0x6C29B594 I believe that the reporting level is only used for errors displayed in the browser window, not to the ones that are logged. The error_reporting setting controls both logged and displayed errors. @Max ... is it possible your application is resetting error_reporting after you set it manually? Maybe try a recursive grep on the source tree for error_reporting. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP Hey Rob, thanks for your reply. No, unfortunately this seems to be a problem with fastCGI, since phpinfo() run somewhere inside the script still says that the error_reporting is set correctly. It just doesn't seem have any influence when errors are logged by the SAPI handler. But since this appears to be not easily changeable right now, I'm going to go with Richard's idea. Thanks all of you for helping! :) Best, Max
