Detecting and correcting problems with applications at early stages is an important role of the server manager. Unfortunately, not all errors are detected at the testing stages. Even more unfortunate is the fact that most errors go undetected because they are usually triggered when a certain set of criteria is met.
Since all you have is 5 minutes (which is one of the tenets of this Server management series, and quite possibly the only simple truth in your case), in this installment, we'll unlock the secret of server log foraging.
All you need is
I don't know what the Beatles would say about this heading, but, indeed,
grep is all you need.
This guide is laid out in two distinct sections:
- Configuring PHP to report errors
- Actually mulling over the server logs
I'm assuming you're using Apache on Linux, of course. I will also assume you have access to your server logs and write permission to the PHP configuration file (usually
Configuring PHP to report errors
Okay, fire up your trusty editor of choice (I use
nano, and that's only because I'm accustomed to
pico — no longer shipped with any Free Software distro — and please let's not get into an editor flamefest here) while being
/etc/php.ini and look for the following configuration keys:
display_errors = On
Set it to
Off. Production PHP applications should not reveal any bugs to the outside world. For the true hacker, the log files will say all that's needed. And, for that, change the following configuration key:
error_reporting = E_ALL
Set it to
E_ALL, because you're interested in warnings, notices and errors. Finally, look for the following configuration key:
log_errors = Off
and set it to
On. Save the file, and restart Apache (here's how).
Let the application run for a couple of minutes (or hours, depending on your visitor volume).
grepping the logs
Now it's time to start working on those logs. Locate your Apache error log file (usually at
/var/log/httpd/error_log. Then use the following command to find all PHP-related error messages:
grep PHP /var/log/httpd/error_log
That may spit out a hefty amount of messages, so you'll probably want to redirect it into a file:
grep PHP /var/log/httpd/error_log > /root/phperrors
The greater-than symbol directs the output of
grep into the file
Inspect the newly created file with your favorite editor and look for messages. Does any of them say
PHP Fatal Error or
PHP Error? If so, you've got a real problem between hands. Warnings are also a cause for concern, because they usually mean an error occurred in your application, but the application just kept going like nothing happened. Notices aren't so much a concern, but they should be dealt with individually, because they usually point to common programming mistakes that must be fixed.
The PHP log messages provide you with another useful tidbit of information: they say the file and line number of the error, notice or warning:
PHP Warning: strtotime() [client 188.8.131.52] PHP Warning: strtotime(): Called with an empty time parameter. in /home/rudd-o/public_html/links.php on line 53, referer: http://rudd-o.com/index.php
That information is very useful to find the source of the problem.
Whether you have to fix errors yourself, or there's a dedicated team behind the Web applications you're overseeing, any PHP-related messages usually pinpoint to issues that need to be paid attention to.
It's also a good idea to automate this procedure into a shell or
CGI script for the developers of the applications you oversee. That way, they'll have a way to get early notice of any issues, and you won't need to be involved in the process. Here's an example shell script that would send those messages to someone at your company, to be run through
#!/bin/bash grep PHP /var/log/httpd/error_log | \ mail -s 'PHP messages' firstname.lastname@example.org
Finally, this procedure should also be standard on testing and staging servers. Finding a problem early on the development stage is invaluable. You really don't know how many customers you may lose to bugs that slip into production.
And that's it for today! Remember, keep your Web applications bug-free, and they'll give lots of value in return. Happy hacking!