Why 404 errors are not saved in Apache error log

In the well configured and a working web server Apache you may encounter an interesting situation – most error messages are saved in logs, but information about requests that returned a response status 404 are disappeared.

Meanwhile, in the access log, 404 Errors are visible.

404 Errors are added to error log for PHP scripts (if no script is found), but not added for HTML files, images, JavaScript files, cascading style sheets, etc. The situation may seem very strange.

You need to know about the Apache web server LogLevel directive. Together with ErrorLog, which determines the path to the log file where errors will be saved, LogLevel is the second necessary directive that determines the level of error seriousness that will be added in the file.

Error levels are as follows:

Level Description Example
emerg Emergencies - system is unusable. "Child cannot open lock file. Exiting"
alert Action must be taken immediately. "getpwuid: couldn't determine user name from uid"
crit Critical Conditions. "socket: Failed to get a socket, exiting child"
error Error conditions. "Premature end of script headers"
warn Warning conditions. "child process 1234 did not exit, sending another SIGHUP"
notice Normal but significant condition. "httpd: caught SIGBUS, attempting to dump core in …"
info Informational. "Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)…"
debug Debug-level messages "Opening config file …"
trace1 Trace messages "proxy: FTP: control connection complete"
trace2 Trace messages "proxy: CONNECT: sending the CONNECT request to the remote proxy"
trace3 Trace messages "openssl: Handshake: start"
trace4 Trace messages "read from buffered SSL brigade, mode 0, 17 bytes"
trace5 Trace messages "map lookup FAILED: map=rewritemap key=keyname"
trace6 Trace messages "cache lookup FAILED, forcing new map lookup"
trace7 Trace messages, dumping large amounts of data "| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
trace8 Trace messages, dumping large amounts of data "| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

The LogLevel directive has a default value, it is as follows:

LogLevel warn

Let's look at an example of errors when a static file is not found (HTML, .txt, .js, etc.):

[Mon Aug 19 05:21:07.846623 2019] [core:info] [pid 29057] [client 2604:a880:2:d0::651:5001:50864] AH00128: File does not exist: /srv/http/suip/.well-known/security.txt

Pay attention to the core:info part, it means that this message comes from the Apache kernel and, most importantly, its level is info! That is, for such messages to fall into the error log, you need to set the LogLevel value to the info level as follows:

LogLevel info

After that, you need to restart the web server and now requests that arise 404 response status will also get into the Apache error log.

The question may arise – why, then, other error messages, for example, that a PHP script was not found, nevertheless fell into the error logs? Let's look at an example entry from the Apache error log:

[Mon Aug 19 05:26:02.847140 2019] [php7:error] [pid 29256] [client] script '/srv/http/suip/wp-login.php' not found or unable to stat

Pay attention to the php7:error field. It means that this message was generated by the php7 module and that this module itself assigned the level to it as ‘error’. The error level is higher than the default ‘warn’ level, for this reason messages about missing .php files are included in the error log by default, and messages about missing other files are not.

What about the next record?

[Mon Aug 19 05:11:51.422362 2019] [authz_core:error] [pid 29056] [client] AH01630: client denied by server configuration: /srv/http/suip/ru/, referer: https://suip.biz/ru/?act=proxy1

The reason for this error is that the request from the user was rejected by the server configuration (banned by IP). This message was generated by the authz_core module, which assigned it an ‘error’ level. This means that even with the LogLevel directive set to ‘warn’ (the default value), this message will still go into the Apache error log.

So, the basic knowledge of the web server directives responsible for error logs allows you to solve the ‘mystical’ problem, in which some entries go to the log and some do not.

Recommended for you:

Leave a Reply

Your email address will not be published.