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 192.168.1.3] user rbowen@rcbowen. com: authentication failure for "/cgi-bin/hirecareers/company.cgi": password mismatch
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 192.168.1.3] 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.