Error log. We will examine the error log to see what is logged and to change the amount of logging done.
log_config_module. We will load and use a module that allows us to configure exactly what we log for each request.
Log file rotation. We will illustrate the SLES system-wide mechanism for log rotation and briefly mention, and then discard, an Apache-specific way to do the same thing.
Legalities. There will be a brief description of the legal implications of keeping log files.
The error log file contains the error reports and warnings from the web server. Under SLES this defaults to the file /var/log/apache2/error_log. The error log is often overlooked, but when things are going wrong it will usually contain useful clues about what the problem is.
By default, the directory /var/log/apache2 is readable only by root. You may want to change this on your system. Within the directory, the files are created world-readable. Only the directory's permissions need be changed.
Let's consider a number of the typical entries in the error log as it currently stands.
[Thu Feb 22 13:14:55 2007] [notice] Graceful restart requested, doing restart [Thu Feb 22 13:14:55 2007] [notice] Apache/2.2.3 (Linux/SUSE) configured -- resuming normal operations
Our first example will be seen in the log files from this course more than any other lines (we hope!). The line that starts "Graceful restart requested" is the logged entry that means we requested a reload of the configuration file.
The line that (hopefully) follows it is the line from Apache that says it has been (re)configured and that it is "resuming normal operations", i.e. serving web pages again.
SIGTERM is an operating system signal with a universal function. It is the instruction to a process to shut down.
[Thu Feb 22 15:14:43 2007] [error] [client 188.8.131.52] File does not exist: /srv/www/WWW/nonsuch.html
Another commonly occurring error_log line is the one corresponding to a request for a file that does not exist.
So far, the error_log lines we have looked at have had a standard format:
We can change the level of the logging (of formatted messages) with the LogLevel command. Either globally, or within specific virtual hosts' sections we can issue the command LogLevel debug, say, to get more debugging.
System is unusable. The entire web service has failed.
"Child cannot open lock file. Exiting"
Action must be taken immediately. The entire web service has either failed already or is imminent danger of failing completely.
"getpwuid: couldn't determine user name from uid"
Critical condition. A child server has failed and others are likely to follow.
"socket: Failed to get a socket, exiting child"
A request on a single request.
"File does not exist: /var/www/WWW/nonesuch.html"
"child process 10108 still did not exit, sending a SIGTERM"
Normal behaviour but worthy of notice.
"Apache/2.0.40 (Red Hat Linux) configured -- resuming normal operations"
"Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..."
"Opening config file ..."
Messages issued from a running web server are well formatted. However, if you make a syntax error in the httpd.conf file then the server won't launch and the error message is rather more stark.
It is also possible to move the error log file, or to do without the file altogether (but still log errors).
The ErrorLog directive gives the name of the error log file. If the file name given is "syslog" then logging is not done to /var/log/apache2/syslog but rather all error logs are passed to the operating system's system logger. This can be useful if you arrange for your system logs to be transmitted off-machine to a central logging engine which you want to receive Apache error logs too.
Finally, if the file name starts with a pipe character, |, then what follows is interpreted as a command which should be forked and executed and which has the error log lines passed to it on its standard input.
Syntax summary: Error logging commands
begins with "/" then this file will be used for
the error log.
is "syslog" then the
error logs will be passed to the system logger with
then the error logs will be passed to the system logger
This must be one of the facilities known to the system
logger; you can't just make up your own.
begins with "|" then
what follows will be run as a command to receive the log
lines on standard input.
Anything else is interpreted as a filename relative to the server root.
Any errors generated at logging levels equal to or
more serious than
level will be