I have created a Shell using CakePHP. I am writing the output to a file using the following command:
sitename/app/Console/cake customconsole >> errorlog.log
Everything seems to work here, but I am not getting the PHP notices or warnings. However, I can see the notices and warnings in the terminal.
Is there any way by which I can log the notices and warnings to my log file as well?
I have made the following changes in php.ini for CLI:
display_errors
Default Value: On
error_reporting
Default Value: E_ALL
I have also adjusted debug value to 1 in CakePHP.
Thanks
A proper written app should not throw notices and hard errors anyway. Besides the attempt to logging them I would invest more time in unit testing and avoiding errors and notices. Specially notices are not hard to correct.
I'm not sure and to lazy to test this right now for you, you can do it yourself, CakePHP is using the console streams for different states, so I guess in the case of a hard php error it's sending the output to the error stream (2).
See this page http://www.ibm.com/developerworks/linux/library/l-lpic1-v3-103-4/ section "Redirecting output" how to redirect all streams in one file.
Try it, it might be the solution.
Related
CodeIgniter 2.x still uses the classic mysql. We all know it's bad practice to still use it, but my job still requires me to use CodeIgniter.
I always have my Console.app (OSX) open watching my Apache/MySQL/PHP/CodeIgniter-native error logs.
Now I mostly have all notices/errors/etc. fixed always instantly when I see them and constantly monitor my development with Webgrind on my MAMP.
Back to the start; I constantly have one big annoying thing each page-load PHP always gives the error about mysql_pconnect is going to get deprecated in the future.
In the CodeIgniter driver the command is suppressed by # to not print the warnings to the screen, but it still ends up in my logs.
Is there any viable way to except one such error specifically in either PHP code or the PHP settings?
Locally I could recompile the whole PHP core and just remove the warning, but I would like to have the logs on our production installations rid of those warnings too :P.
Thanks in advance!
Traditionally, you can use set error verbosity using error_reporting(E_ALL ^ E_NOTICE ^ E_DEPRECATED) (i.e., report everything—except notices and deprecation warnings) as mentioned in "disabling deprecated errors".
Your issue may be related to CodeIgniter taking ownership of all errors.
system/core/CodeIgniter.php calls the function set_error_handler. You can find and modify the function _exception_handler it invokes on error in system/core/Common.php. It doesn't appear to be a configurable, so you may simply want to edit the line that begins with $is_error.
I managed to run MongoDB on Codeigniter using Alex Bilbie` library. The operations go well (connection, queries etc. ) but sometimes I get these PHP notices:
Message: Mongo::__construct() [mongo.--construct]: localhost:27017: pool get (0x4bfab20)
Filename: libraries/Mongo_db.php
Line Number: 1274
A PHP Error was encountered
Severity: Notice
Message: Mongo::__construct() [mongo.--construct]: localhost:27017: found in pool (0x4bfab20)
Filename: libraries/Mongo_db.php
Is there a way to get rid of these? or maybe hide them..as they don't seem to mess up my pages in another way than splashing into the user's screen.
EDIT
On a few pages though, I use the JQgrid and when the errors show up they mess up my HTTP response and render some messy data.
The specific notice messages here have been removed in the MongoDB PHP driver 1.2.11 or later (see PHP-431). Upgrading your MongoDB driver to the latest should remove the excessive notice logging.
General notes on proper settings for Code Igniter logging in production still apply...
The E_NOTICE level of error reporting is intended to warn you about possible bugs or typos. It is typically only used as a development setting rather than for production messages.
The default error_reporting setting in PHP4 and PHP5 is actually set to ignore these:
E_ALL & ~E_NOTICE
The Code Igniter index.php has an application environment setting which normally shows all errors for development and suppresses error reporting for testing and production. You should set this appropriately:
define('ENVIRONMENT', 'production');
If you actually want to capture these messages for a production environment you should update the production settings in your index.php so that instead of error_reporting(0) you have:
error_reporting() set to appropriate level of detail
display_errors off
log_errors on
error_log path set
For example, in index.php you could have:
case 'production':
error_reporting(E_ALL);
ini_set('display_errors','Off');
ini_set('log_errors','On');
ini_set('error_log','/var/log/php5.log');
break;
That way the messages/notices will still be saved to the error_log if you want to review them, but they will not be shown to the end user.
Off the top of my head, there are a few things you could do. This is not an answer regarding a fix to the MongoDB error you are receveing, but rather regarding some methods in which you could hide the errors.
a) Use the '#' operator to ignore any error outputs from the method being called in which outputs the errors you are receiving. This would result in you renaming the method call to the following #method_outputting_mongodb_error($foo,$bar);.
b) Turn off error reporting in CodeIgniter. This is not the best method as all other errors will not be outputted.
There is a good link here re: how you can turn off error reporting: http://phpdog.blogspot.fr/2012/02/codeigniter-error-reporting-handling.html
As #Stennie mentions this has been fixed in later versions of the driver: https://jira.mongodb.org/browse/PHP-431
Try and upgrade.
Also this only existed on the Windows driver and only start happening after v1.2.1. I know that because the guy who made that JIRA also tried 1.2.1 on my advice and he didn't get those E_NOTICEs. I remember having the conversation that actually triggered that JIRA now :).
Unlike others I don't think you should "hide" these errors with E_ALL & ~E_NOTICE. No one is quite decided on hiding E_NOTICE however the general concensus is that it is not the best thing. Of course you would not want your logs to be filled with all this debug info about the MongoDB extension, instead the MongoDB extension should be silent (as you think it should).
Another reason I would not hide E_NOTICE is because of the php.ini of later versions of PHP:
; error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
By default PHP will actually install for Production Value (as it does for me) as such the default for PHP error reporting is:
E_ALL & ~E_DEPRECATED
This is the value I have for error_reporting on both my AWS and my local Ubuntu server 12.04 and I have not changed the values since installing as such the default value I gain from installing PHP from both repo and source is:
error_reporting = E_ALL & ~E_DEPRECATED
So the recommended default setup for production for later PHP versions (and probably future ones) actually shows E_NOTICE, which is useful but not if the logs are being filled with stuff from the Mongo extension.
Edit: Downvoter care to explain? I have basically given the same answer as #Stennie, why the downvote?
I have edited my answer to actually take the conversation in the comments on this answer and #Stennie's answer into consideration so the answer makes more sense now.
I am doing a lot of development with CodeIgniter these days and I am extremely irriated with the lack of debugging features in CI.
It does throw errors if a view file is missing and so on. But when I forget to put a semicolon somewhere it simply does not throw any error.
I ensured now and again that error level is set to E_ALL, I checked the logs but nowhere the syntax errors are getting captured. This wastes a lot of my time.
I find that the best way to deal with this situation is to use an editor with PHP syntax checking. From the command line you can also run
php -l filename.php
to syntax check your file.
You can turn on syntax error reporting in your php.ini, but it is disabled by default.
set
display_errors on
along with your
error_reporting E_ALL
One alternative is to use an IDE like Eclipse in debug mode to step through the code. Once Eclipse is set up properly, it can step through trace points and display the status of each operation, line by line. It can be a real time saver.
If you have actual syntax errors in your PHP, I don't think there's any way for a PHP framework, such as CodeIgniter, to catch them.
I would like to log PHP errors on a CakePHP site that has debug = 0. However, even if I turn on the error log, like this:
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
log_errors = On
it doesn't log errors.
The problem is that even for a parse error that should cause the CakePHP environment to not load completely (I think), it still blocks the error from being logged. If I set debug to 3, it logs to the file without issue.
I am using CakePHP 1.2. I know this is apparently made easier in 1.3, but I'm not ready to upgrade.
Another way to keep track of and log errors would be to use the Referee plugin as it provides a way to arbitrarily log and catch all (including fatal) errors that occur during exection.
define('LOG_ERROR', 2); in core.php
PHP should log errors to its own logfile, regardless of what CakePhp is doing.
Look in /etc/php.ini file (or wherever yours lives) and search for error_log. This will show you where the PHP log resides on your system.
There is a bug in CakePHP 1.2-1.3 where PHP errors/warnings are suppressed in view code when debugging is disabled.
In the file cake/libs/view/view.php on line #664 it reads
#include ($___viewFn);
But the # directive suppresses errors for the entire view handler. Instead it should be:
include ($___viewFn);
Which allows PHP errors/warnings to be generated in view code and subsequently get logged. Once I changed this and had the right logging settings in core.php I was finally able to get complete logs in production.
Sometime the reason could be very different. For example the framework you are using may have its own internal caching module which keeps the value in buffer while you keep on trying. Check whether duplicate copies are getting generated or not. Typically those files would be named as filename.ext.r123 and so on.
Let's say I'm basically inheriting a live site that has a lot of errors in production, I'm basically doing a recode of this entire site which might take a month or so.
There are some cases in which this site was reliant upon external xml file feeds which are no longer there, but the code wasn't properly setup to supply a nice clean error message ( there are various similar circumstances ) - the client is requesting that at least these error messages go away even if for example the content from the xml file isn't published so we wouldn't be seeing php errors and a blank region on the page ( so the rest of the page can look "fine" ).
At one point I have heard of someone using set_error_handler to nullify some cases where it isn't extreme and I had the idea of setting it up to store error messages in a file/log or email them ( and try to not have duplicate error messages ) basically so end users don't have to see those ugly things.
I'm looking for tips from anyone who's actually done this, so thanks in advance.
On your production server, you should have the following ini settings:
ini_set('error_reporting', E_ALL | E_STRICT);
ini_set('log_errors', true);
ini_set('error_log', '/tmp/php_errors.log'); // or whatever file is appropriate
ini_set('display_errors', false);
By turning off display_errors, your users will never see another error message, but you will be able to see error messages by looking in the log file.
When the re-code is finished, there should be no more errors going into the log file (because you've fixed them all).
Edit: Some developers set error_reporting to E_ALL ^ E_NOTICE as a way of hiding errors. This is bad practice because it hides messages about possible programming errors. You should only use E_ALL ^ E_NOTICE when there are so many Notices coming from legacy code that you are unable to fix them all.
When in development, it is good to use
error_reporting(E_ALL);
ini_set('display_errors', 'On');
So you can see errors immediatly : it helps correcting them.
When on the production server, you don't want error displayed, so :
ini_set('display_errors', 'Off');
error_reporting can remain activated : if display_errors is Off, errors won't be displayed anyway -- but you can still have them logged to a file.
BTW, those can be set in the php.ini file, of course :
error_reporting
display_errors
On the production machine, you might want to use log_errors and error_log, so errors are logged to a file (which means you will be able to know what errors occured -- can be useful, sometimes) ; of course, don't forget to check that file from time to time ;-).
As a sidenote, if you just have a couple functions/methods you don't want to display errors, you could envisage using the # operator to just mask the errors those might trigger...
... But I strongly advise against it (except in very specific cases) : it make debugging lots harder : errors triggered there are never displayed, not even on your development machine !
In my opinion, it is way better to just disable display_errors on the production machine ; it also means no error will be displayed at all, which is better for users!