When writing configuration files for Apache web server I would like to have a quick feedback loop.
I, for example have a script that doesn't seem to work. It is either not picked up, or the variables I use are not set, or maybe overriding is not allowed. How to debug this?
I expected to at least print some debug log statements like REQUEST_URI: %{REQUEST_URI}. Can't find such a thing.
apachectl is a front end to the Apache HyperText Transfer Protocol (HTTP) server. It is designed to help the administrator control the functioning of the Apache httpd daemon.
Here is a link to the documentation.
Different platform might use different binary names such as apache, apache2 or apache2ctl. To test the configuration - just run:
apachectl configtest
# or, depending on your OS
httpd -t
EDIT
If you are trying to debug your virtual host configuration, you may find the Apache -S command line switch useful. That is, type the following command:
httpd -S
This command will dump out a description of how Apache parsed the configuration file
my Apache2 on Ubuntu 16.04 runs mpm_event, but on every Security Update Apache switch back to mpm_prefork. Why and how can I disable this, so mpm_event is still configured?
I found this: https://ubuntu101.co.za/apache-web-server/fix-apache-2-4-loading-wrong-mpm-worker-module/
But this don't work for me. After a security update I get the error message: "No MPM is configured". So my Apache don't run.
Did you have an idea?
Same problem. However, I found that if I commented out the lines as described in https://ubuntu101.co.za/apache-web-server/fix-apache-2-4-loading-wrong-mpm-worker-module/ but then also added the line below underneath the commented-out lines in each file, mpm_prefork was disabled when updating. This worked for me on both Ubuntu 16.04 and 18.04.
LoadModule mpm_event_module /usr/lib/apache2/modules/mod_mpm_event.so
Doing this generated warnings about php-fpm and proxy_fcgi not being enabled but checking showed that they were actually still enabled.
Following the installation instruction, JIRA is now available on :
http://example.com:8080/
However I want it to be accessible on http://jira.example.com.
I followed these instruction : https://confluence.atlassian.com/jira/integrating-jira-with-apache-185729645.html
Now http://example:8080/ redirects on http://jira.example.com but nothing gets displayed.
Any ideas on how I could solve it ?
ps : I am restarting the httpd with "service httpd restart" after each changes.
The issue is that jira.example.com cannot be resolved at all. I suspect you may not have DNS entries in place to resolve to your server. For local testing you could try a hosts file override, but you'll need to modify DNS records in order to resolve this further abroad.
Once resolved in DNS you should have JIRA or Apache errors to further investigate/debug, or if you're lucky you'l have a working JIRA server :)
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.
I'm setting up a cluster of servers for the company I work at, and I'm using Monit to monitor that all server processes are running and working as they should.
For Apache monitoring, I wanna use the mod_status feature which is explained here. However, this has turned out quite difficult. As no matter how I configure both Monit and Apache, Monit just keeps reporting a connection failure error (connection failed to 127.0.0.1:80 [APACHESTATUS via TCP]).
I followed the instructions on the Monit Wiki without much luck. The Apache status page (http://127.0.0.1/server-status?auto) page works in any browser I test it with. I've also tried changing host the from 127.0.0.1 to localhost without any luck.
I've tested this setup with Monit versions 4.8.x, 4.10x, and 5.0-beta6, all with the same result. Also, there's not much useful info on Google to help either, as most results are about more trivial and simple problems.
Am I missing something? Or am I just plain stupid maybe?
Try to change the authorization in Apache:
Order allow,deny
Allow from all
Check Apache access.log and error.log files - which kind of error is reported ?