404 error doesn't appear in Apache error.log - apache

If a visitor gets 404 error, nothing is written in apache error.log. In access log it appears like this:
GET /qqq HTTP/1.1" 404 409 "-"
And nothing in error.log. I have tried everything about LogLevel. As I understand, it is because that 404 page is custom page like
ErrorDocument 404 /new404.html
But I run search through all /etc/apache2 for text "404" in files and nothing was found there (instead of commented lines). What can be the problem? Or maybe I can somehow disable custom 404 page in .htaccess file? Or any other ways to display 404 errors in error.log?

As the person who filed the Apache bug which demoted 404 from Error to Info level as of Apache 2.4.1, here's the justification:
In production HTTP servers open to the Internet, 404s happen all the time. Malware, scanner scripts, and all sorts of other things probe Web servers for vulnerabilities or just because they can, and these things would all trigger errors which will end up being logged somewhere if the appropriate error level is set.
Most production Web server admins are content with seeing 404s in their access logs (which are logged right alongside 200s and 30x redirects), and want to see real server problems -- things they have control over fixing -- in the error log. The logging of 404s in error.log can, in some servers, be so much log spam that it drowns out legitimate problems needing the administrator's attention.
404 is a content issue, not a server issue. So my recommendation is to look in your access.log (or equivalent) for them. If you really want content related issues logged in error.log, you need to set LogLevel core:info. This will give you 404s there, and a few other kinds of content-related error messages too.

404 "errors" don't normally appear in the Apache error log, regardless of whether you have a custom ErrorDocument defined or not.
A 404 error is not strictly a server error. It's an expected HTTP response, so it naturally appears in the access log (as you have stated), not in the error log. The "404" is the HTTP response code, not a server error code.
However, you should be able to enable additional "information" messages in your error logging (eg. LogLevel info on Apache 2.4) to get this "information" in your system error log:
[Mon Feb 06 08:00:00.090525 2017] [core:info] [pid 13876:tid 1748] [client 203.0.113.111:54493] AH00128: File does not exist: /home/user/public_html/path/to/file
Note, however, that there is no mention of "404" - which maybe why your searches came up blank. This LogLevel should not be maintained on a production server.

Maybe this helps somebody...
I had zombie apache instances running (with a slightly different config loaded), and every other request for a static resource defined using an Alias was 404-ing.
Killed the zombies and all good...

404 is a server response, not a error.
You can get the 404 log doing something like:
cat /var/log/apache2/access_log | grep " 404 " | awk -F' ' '{print $4," ",$5,"-",$7}' > /root/404.log
and adjust the awk as you need!

Related

Is there a way to serve julia from the cgi-bin directory with apache?

I have a user who wants to serve output of julia files from an apache webserver.
Placing the code in there, adding .jl to AddHandler, and chmod 775 the file gets a 500 internal server error.
helloworld.jl: -rwxr-xr-x
println("hello world")
Here is what is displayed from apache:
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, root#localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.```

Why isn't apache serving the page? mod_rewrite seems to have found the right file

The project I'm working on has a fairly long & complicated list of RewriteRules, separated into 2 .htaccess files for legacy reasons. I'm putting the app into a Docker container to make it easier to on-board new developers, but the Ubuntu/Apache combo is choking on the RewriteRules and giving me an HTTP 500.
Docker image: php:5.6-Apache
Apache Version: 2.4
I boosted the logging to trace4 and it appears to figure out the right file - here's the last line of the mod_rewrite debug output
[Thu Mar 16 09:08:15.459987 2017] [rewrite:trace1] [pid 17] mod_rewrite.c(475): [client 192.168.99.1:63990] 192.168.99.1 - - [rs.dev/sid#7f51cf6fece0][rid#7f51cf61c8f8/initial/redir#3] [perdir /var/www/appname/public_html/production/] pass through /var/www/appname/public_html/production/login.php
The file '/var/www/appname/public_html/production/login.php' exists, and is the file that should be loaded. However, the response is sent as a 500, (and the page doesn't load). I'm using the /login URL here as an example, but it happens on all URLs.
This works on the localhost of a Mac running macOS, and it works in cPanel servers, I just can't seem to get it running in the Ubuntu base that Docker's providing me.
Does anyone know why Apache would use mod_rewrite and appear to identify the correct file, but then not use the file?
For reference, the entire log output from the request is on pastebin.
It turns out that my problem wasn't in the Rewriting at all, I had forgotten to create a file that PHP was trying to require, so it was throwing a PHP error. However, the way the logs were configured, the error was disappearing into the ether, (or into a log I haven't found yet).
Let that be a lesson - even if you're absolutely sure where the error is, you might still be wrong!

Bots throws 500 error in apache access log

In my Apache error log I can see the following errors has caught on enormous amount everyday.
[Tue Jan 15 13:37:39 2013] [error] [client 66.249.78.53] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
When I check the corroesponding IP, Date and Time with the access log I can see the following
66.249.78.53 - - [15/Jan/2013:13:37:39 +0000] "GET /robots.txt HTTP/1.1" 500 821 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
I've tested my robot.txt file in the Google Webmster tool -> Health -> Blocked URLs and it's fine.
Also when some images accessed by bot's it throw the following error,
Error_LOG
[Tue Jan 15 12:14:16 2013] [error] [client 66.249.78.15] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
Accessed_URL
66.249.78.15 - - [15/Jan/2013:12:14:16 +0000] "GET /userfiles_generic_imagebank/1335441506.jpg?1 HTTP/1.1" 500 821 "-" "Googlebot-Image/1.0"
Actually the above image URL (and several other images in our access log) are not available on our site (they were available before a website revamp that we did in August 2012), and we thrown 404 errors when we go to those invalid resources.
However once in a while, it seems that bots (and even human visitors) generate this type of error in our access/error log, only for static resources like images that don't exist, and our robots.txt file. The server throws a 500 error for them, but actually when I try it from my browser - the images are 404 and the robots.txt is 200 (success).
We are not sure why this is happening and howcome a valid robot.txt and inavalid image can throw a 500 error. We do have a .htaccess file and we are sure that our (Zend framework) application is not being reached, because we have a separate log for that. Therefore, the server itself (or.htaccess) is throwing the 500 error "once in a while" and I can't imagine why. Could it be due to too many requests to the server, or how can I debug this further?
Note that we only noticed these errors after our design revamp, but the web server itself stayed the same
It might be useful to log the domain that the client is accessing. Your server might be accessible via multiple domains, including the raw IP address. When you're testing, you're doing so via the primary domain and everything works as expected. What if you try to access the same files via your IP (http://1.2.3.4/robots.txt) vs. the domain (http://example.com/robots.txt)? Also example.com vs. www.example.com or any other variation that points to the server.
Bots can sometimes hold on to IP/domain info long after an address has changed and may be attempting to access something that the rules were changed for months ago.

Internal Error 500 Apache, but nothing in the logs?

I'm getting 500 Internal Server errors when I try to make an HTTP POST to a specific address in my app. I've looked into the server logs in the custom log directory specified in the virtual hosts file, but the error doesn't show up there so debugging this has been a pain in the ass.
How do I cause Apache to log Internal 500 errors into the error log?
This is an Ancient answer from 2013, back when PHP was new and security wasn't an issue:
Here in the future it's a security risk to dump errors to screen like this. You better not be doing this in any production setting.
Why are the 500 Internal Server Errors not being logged into your apache error logs?
The errors that cause your 500 Internal Server Error are coming from a PHP module. By default, PHP does NOT log these errors. Reason being you want web requests go as fast as physically possible and it's a security hazard to log errors to screen where attackers can observe them.
These instructions to enable Internal Server Error Logging are for Ubuntu 12.10 with PHP 5.3.10 and Apache/2.2.22.
Make sure PHP logging is turned on:
Locate your php.ini file:
el#apollo:~$ locate php.ini
/etc/php5/apache2/php.ini
Edit that file as root:
sudo vi /etc/php5/apache2/php.ini
Find this line in php.ini:
display_errors = Off
Change the above line to this:
display_errors = On
Lower down in the file you'll see this:
;display_startup_errors
; Default Value: Off
; Development Value: On
; Production Value: Off
;error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
The semicolons are comments, that means the lines don't take effect. Change those lines so they look like this:
display_startup_errors = On
; Default Value: Off
; Development Value: On
; Production Value: Off
error_reporting = E_ALL
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
What this communicates to PHP is that we want to log all these errors. Warning, there will be a large performance hit, so you don't want this enabled on production because logging takes work and work takes time, time costs money.
Restarting PHP and Apache should apply the change.
Do what you did to cause the 500 Internal Server error again, and check the log:
tail -f /var/log/apache2/error.log
You should see the 500 error at the end, something like this:
[Wed Dec 11 01:00:40 2013] [error] [client 192.168.11.11] PHP Fatal error:
Call to undefined function Foobar\\byob\\penguin\\alert() in /yourproject/
your_src/symfony/Controller/MessedUpController.php on line 249
I just ran into this and it was due to a mod_authnz_ldap misconfiguration in my .htaccess file. Absolutely nothing was being logged, but I kept getting a 500 error.
If you run into this particular issue, you can change the log level of mod_authnz_ldap like so:
LogLevel warn authnz_ldap_module:debug
That will use a log level of debug for mod_authnz_ldap but warn for everything else (https://httpd.apache.org/docs/2.4/en/mod/core.html#loglevel).
Check your php error log which might be a separate file from your apache error log.
Find it by going to phpinfo() and check for error_log attribute.
If it is not set. Set it: https://stackoverflow.com/a/12835262/445131
Maybe your post_max_size is too small for what you're trying to post, or one of the other max memory settings is too low.
If your Internal Server Error information doesn't show up in log files, you probably need to restart the Apache service.
I've found that Apache 2.4 (at least on Windows platform) tends to stubbornly refuse to flush log files—instead, logged data remains in memory for quite a while. It's a good idea from the performance point of view but it can be confusing when developing.
Please Note: The original poster was not specifically asking about PHP. All the php centric answers make large assumptions not relevant to the actual question.
The default error log as opposed to the scripts error logs usually has the (more) specific error. often it will be permissions denied or even an interpreter that can't be found.
This means the fault almost always lies with your script. e.g you uploaded a perl script but didnt give it execute permissions? or perhaps it was corrupted in a linux environment if you write the script in windows and then upload it to the server without the line endings being converted you will get this error.
in perl if you forget
print "content-type: text/html\r\n\r\n";
you will get this error
There are many reasons for it. so please first check your error log and then provide some more information.
The default error log is often in /var/log/httpd/error_log or /var/log/apache2/error.log.
The reason you look at the default error logs (as indicated above) is because errors don't always get posted into the custom error log as defined in the virtual host.
Assumes linux and not necessarily perl
The answers by #eric-leschinski is correct.
But there is another case if your Server API is FPM/FastCGI (Default on Centos 8 or you can check use phpinfo() function)
In this case:
Run phpinfo() in a php file;
Looking for Loaded Configuration File param to see where is config file for your PHP.
Edit config file like #eric-leschinski 's answer.
Check Server API param.
If your server only use apache handle API -> restart apache.
If your server use php-fpm you must restart php-fpm service
systemctl restart php-fpm
Check the log file in php-fpm log folder. eg /var/log/php-fpm/www-error.log
Please check if you are disable error reporting somewhere in your code.
There was a place in my code where I have disabled it, so I added the debug code after it:
require_once("inc/req.php"); <-- Error reporting is disabled here
// overwrite it
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
Add HttpProtocolOptions Unsafe to your apache config file and restart the apache server. It shows the error details.
In my case it was the ErrorLog directive in httpd.conf. Just accidently noticed it already after I gave up. Decided to share the discovery )
Now I know where to find the 500-errors.
Check that the version of php you're running matches your codebase. For example, your local environment may be running php 5.4 (and things run fine) and maybe you're testing your code on a new machine that has php 5.3 installed. If you are using 5.4 syntax such as [] for array() then you'll get the situation you described above.
Try accessing a static file. If this is not working either then
go to all directories from the root "/" or "c:\" to the directory of your file and check if they contain ".htaccess" files.
I once left a file in "c:\" and it had the most strange results.

Apache: multiple ../ in query string = internal server error (error 500)

here's the problem: when requesting url like - http://server/path/to/file.html?param=../../something/something i get response:
500 Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
...
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
log says:
xxx.xxx.xxx.xxx - - [05/Mar/2010:13:43:29 -0500] "GET /path/to/file.html?param=../../something/something HTTP/1.1" 404 - "-" ...
if i remove one instance of '../' in query string (request http://server/path/to/file.html?param=../something/something ), i get the reqested page. it gives error only on two or more '../'s.
this is on some hosting server, and the same thing gives no error on my local servers (LAMP, WAMP). i suppose it's about apache configuration, but i don't know what options to check.
Apache2.2.14 (Unix) is in question, PHP is installed (but it clearly doesn't have anything to do with PHP when i'm requesting plain ol' HTML file), mod_rewrite rules are disabled (no .htaccess files in requested file's path).
any ideas on how to succeed passing multiple '../'s in query string?
turned out to be security precaution enabled by default by hosting provider - not allowing 'backpaths', but i'm not sure which one, and where it's set.