5 minutes to finding issues in production PHP Web applications

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 grep.

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 /etc/php.ini).

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 root. Open /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 /root/phperrors.

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 157.100.84.91] 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.

Conclusions

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 cron:

#!/bin/bash

grep PHP /var/log/httpd/error_log | \
    mail -s 'PHP messages' someone@yourcompany.com

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!