Apache Guide: Logging, Part 2 -- Error Logs Page 2

First, we have the date/time stamp. And the first thing that you might notice is that the format is not the same as the format in the access_log. The format that we called the "standard english format." I suspect that this is an accident of history, and that it's probably too late to change it now. I'll have to delve into this a little further and find out.

Next, we have the level of the message. This will be one of the levels specified in the documentation for LogLevel (see link above). error is right between warn and crit. This simply indicates how serious the problem is. A 404 error means that you irritated someone, but your server is not actually on fire.

The next field indicates the address of the client machine that made the request. In this case, it is a machine on my local network.

The last part of the log entry is the actual error message. In the case of a 404, it gives you the full path of the file that the server tried to serve. This is particularly useful when you're getting a 404 on a file that you just know is there. Frequently you have a configuration wrong, or the file is on a different virtual host than you thought, or some other strangeness.

Authentication errors will look very much the same:

        [Tue Apr 11 22:13:21 2000] [error] [client] user rbowen@rcbowen.
        com: authentication failure for "/cgi-bin/hirecareers/company.cgi": password

Note that document errors, since they are a direct result of a client request, will be accompanied by an entry in access_log as well.

CGI Errors

Perhaps the most useful use of the error is troubleshooting misbehaved CGI programs. Anything that a CGI program emits to STDERR (Standard Error) gets spewed directly to the error log for your perusal. This means that (well-written) CGI programs, when they go south, will tell you, via the log file, exactly what the problem is.

The downside to this is that you end up with stuff in the error log that is not in any well-defined format, and so it makes it very hard to have any automatic error-log parsing to get useful information out.

What follows is an example of an entry in my error log from when I was hacking on some Perl CGI code:

        [Wed Jun 14 16:16:37 2000] [error] [client] Premature 
        end of script headers: /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi
        Global symbol "" requires explicit package name at 
        /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81.
        Global symbol "%details" requires explicit package name at 
        /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84.
        Global symbol "" requires explicit package name at 
        /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133.
        Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi 
        aborted due to compilation errors.

OK, this entry actually does follow the same format as the 404 error above, in that it has a date, error level, and a client address. But the error message itself is several lines long, which tends to confuse some log-parsing software.

Now, even if you don't know Perl, you should be able to look at the error messages above, and glean some useful information about what went wrong. At the very least, you can tell on what lines I screwed up. Perl is really good about telling you where you made a mistake. Your mileage may vary, based on what language you are using.

This article was originally published on Aug 28, 2000
Page 2 of 3

Thanks for your registration, follow us on our social networks to keep up-to-date