How can I make PHP display the error instead of giving me 500 Internal Server Error [duplicate] - apache

This question already has answers here:
How can I get useful error messages in PHP?
(41 answers)
Closed 5 years ago.
This has never happened before. Usually it displays the error, but now it just gives me a 500 internal server error. Of course before, when it displayed the error, it was different servers. Now I'm on a new server (I have full root, so if I need to configure it somewhere in the php.ini, I can.) Or perhaps its something with Apache?
I've been putting up with it by just transferring the file to my other server and running it there to find the error, but that's become too tedious. Is there a way to fix this?

Check the error_reporting, display_errors and display_startup_errors settings in your php.ini file. They should be set to E_ALL and "On" respectively (though you should not use display_errors on a production server, so disable this and use log_errors instead if/when you deploy it). You can also change these settings (except display_startup_errors) at the very beginning of your script to set them at runtime (though you may not catch all errors this way):
error_reporting(E_ALL);
ini_set('display_errors', 'On');
After that, restart server.

Use php -l <filename> (that's an 'L') from the command line to output the syntax error that could be causing PHP to throw the status 500 error. It'll output something like:
PHP Parse error: syntax error, unexpected '}' in <filename> on line 18

It's worth noting that if your error is due to .htaccess, for example a missing rewrite_module, you'll still see the 500 internal server error.

Be careful to check if
display_errors
or
error_reporting
is active (not a comment) somewhere else in the ini file.
My development server refused to display errors after upgrade to
Kubuntu 16.04 - I had checked php.ini numerous times ... turned out that there was a diplay_errors = off; about 100 lines below my
display_errors = on;
So remember the last one counts!

Try not to go
MAMP > conf > [your PHP version] > php.ini
but
MAMP > bin > php > [your PHP version] > conf > php.ini
and change it there, it worked for me...

Enabling error displaying from PHP code doesn't work out for me. In my case, using NGINX and PHP-FMP, I track the log file using grep. For instance, I know the file name mycode.php causes the error 500, but don't know which line. From the console, I use this:
/var/log/php-fpm# cat www-error.log | grep mycode.php
And I have the output:
[04-Apr-2016 06:58:27] PHP Parse error: syntax error, unexpected ';' in /var/www/html/system/mycode.php on line 1458
This helps me find the line where I have the typo.

If all else fails try moving (i.e. in bash) all files and directories "away" and adding them back one by one.
I just found out that way that my .htaccess file was referencing a non-existant .htpasswd file. (#silly)

Related

Apache httpd server on windows won't start

I installed Apache on Windows7 through a bitnami install package for trac. As a final installation step the installer tried to start the Apache httpd service and threw up an error that starting the https service failed.
I found out why when I tried to start httpd from command prompt and got this error:
AH00526: Syntax error on line 564 of F:/Bitnami/trac-1.0.9-0/apache2/conf/httpd.conf:
SetEnv takes 1-2 arguments, an environment variable name and optional value to pass to CGI.
Here is the offending line:
SetEnv PATH "${PATH};F:/Bitnami/trac-1.0.9-0/apache2/bin;"
I changed it to this:
SetEnv PATH "F:/Bitnami/trac-1.0.9-0/apache2/bin;"
and the service started.
My questions are:
1) What is the syntax/language used in the httpd.conf file?
2) How would one have to change that line to make it compile and preserve the original intent of appending F:/Bitnami/trac-1.0.9-0/apache2/bin to the environment variable PATH?
3) Assuming this works on some platforms why would it not work on Windows?
Thanks.
Update
Like the responses say the issue was with PATH. However the fact that there are spaces in the paths doesn't appear to be the issue. Not only that I isolated the path in PATH that was causing the problem. It was this "C:\tools\mkstools", exactly like that. I got rid of the quotes and that enabled httpd to start. So I'm still scratching my head. Why would the quotes cause the problem?
For me, it worked by replacing ${PATH} with %PATH%.

cgi-bin returning internal server error due to compilation failure

I moved my script to a new server with almost identical configuration (apache/centos) but the cgi-bin has been failing to work ever since. For past one week I have googled every possible solution and isolated the error by executing script from command line. Output i get is as follows for a simple test file:
[root /var/foo/public_html/cgi-bin]# perl -dd /var/foo/public_html/cgi-bin/test.cgi
Loading DB routines from perl5db.pl version 1.32
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(/var/foo/public_html/cgi-bin/test.cgi:2):
2: print "Content-type: text/plain\n\n";
Unknown error
Compilation failed in require at /usr/local/share/perl5/Term/ReadLine/Perl.pm line 63.
at /usr/local/share/perl5/Term/ReadLine/Perl.pm line 63
Term::ReadLine::Perl::new('Term::ReadLine', 'perldb', 'GLOB(0x18ac160)', 'GLOB(0x182ce68)') called at /usr/share/perl5/perl5db.pl line 6073
DB::setterm called at /usr/share/perl5/perl5db.pl line 2237
DB::DB called at /var/foo/public_html/cgi-bin/test.cgi line 2
Attempt to reload Term/ReadLine/readline.pm aborted.
Compilation failed in require at /usr/local/share/perl5/Term/ReadLine/Perl.pm line 63.
END failed--call queue aborted at /var/foo/public_html/cgi-bin/test.cgi line 63.
at /var/foo/public_html/cgi-bin/test.cgi line 63
[root /var/foo/public_html/cgi-bin]#
The code of the test file I am using is:
#!/usr/local/bin/perl
print "Content-type: text/plain\n\n";
print "testing...\n";
I have checked the path to perl, perl version etc etc and everything seems to be ok. However the script is not exceuting and gives a 500 internal server error. I am running php5 with dso handler and susEXEC on. susEXEC logs does not say anything except that the cgi script has been called. This problem is completely baffling me and my little experience with cgi/perl is not helping. Can anyone point me in a right direction to solve this?
As someone commented already check the permissions and also try to run the file from the console.
A likely problem is that when you switched servers the path to perl changed and your shebang line is wrong. A common technique to avoid this is to use #!/usr/bin/env perl instead.
When you recieve a 500 error apache should also log something in the error log (your vhost config might define a custom error log instead the default one so check that if you're having trouble finding the error message.
Also there is no reason to run your script under the Perl Debugger, unless your goal is to experiment with the Perl Debugger (and with no variable defined it is pointless as an example). My advice is don't use the Perl Debugger. A lot of experienced Perl programmers, (probably a big majority) never or rarely use it.
I solved this eventually, posting it for the sake of posterity:
On moving server I mounted the filesystem on a different partition as the home partition ran out of memory. I forgot to give exec permissions to the new mountpoint, that's why the cgi scripts were not executing.

httpd.config error when insntalling mod_wsgi+django

its been more than 2 weeks. i try to instal but still getting error.
firstly, indeed I have searched similar error but i didn't find solution at all. if you find it. please let me know.
second, this is my state :
1. i have installed python 2.7 and django 1.5.1 (it works).
2. i also install MAMP.
3. i try to configure mod_wsgi and want it integrated with my MAMP apache server.
4. using mac mountain lion 10.8.4
my configuration file :
/etc/apache2/original/extra/httpd-userdir.conf inside my apache2/original/extra/
/etc/apache2/users/akhyar.conf pastebin.com/zcY58WTV (sorry about this Iam new on stack overflow)
/etc/apache2/httpd.conf pastebin.com/je2D8zMz
third, this is my error :
when i run apachectl configtest this error appears my error
so, what is going on actually? can someone tell me why and show me the mistakes?
if its been solved, what is the next step for configuring mod_wsgi on my MAMP?
thanks before, any help are highly appreciated.
In this file, line 15, you're including the per-user conf files:
http://pastebin.com/7y7ibuqP
On line 473 of this one, one of those per-user conf files, you're including the above file again:
http://pastebin.com/zcY58WTV
This causes infinite recursion while trying to parse the conf files.
I think there are some other errors too, and to be honest the files are pretty messy, but the best way forward is to remove all Include directives from akhyar.conf. For the most part they're already duplicates, where they're not, inline the contents of those files instead of using Include. If there are other errors, you'll at least see useful line numbers to start tracking them down.
Also note that the [warn] lines are just warnings - which you should probably fix, but the server will still run without them, that's not what's causing the error.

codeigniter project migration from iis to apache2

I have migrated my project from Windows IIS to Mint Apache2.
Unfortunately I am getting an error:
HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfil the request.
I have changed permissions on the files to 755. Normally if there is a CI error (connecting to db etc) it throws an error.
I have opened my index.php with VI, and I have noticed ^M on the end of each line in EACH FILE. This doesn't show in Aptana though.
I have spent last half a year writing this app and I'm not very excited about this.
Does anybody have any experience with this?
Thank you.
If you have access to the shell on your server and it's running Linux/Unix, try this:
for i in `find . -type f` ; do dos2unix $i $i; done
The for i in `find . -type f` ; part finds all FILES within the current directory.
Then, do dos2unix $i $i; done runs dos2unix which will convert all your ^M's to the Unix standard which is just \r.
If you want to test it out on a single file, make a copy of a file and replace find . with find filename.ext
Try adding this to your php.ini.
display_errors = On
This should show a proper error instead of just throwing a 500. From therein it should be relatively simple to debug.

suPHP upgrade causing 500 internal server error

I have my server perform a yum update every night. Last night, it updated suPHP to the newest version:
Oct 16 01:25:43 Updated: mod_suphp-0.7.1-1.el5.art.x86_64
This update has caused my website to throw a 500 internal server error. From what I've been able to find, I should only have to change the last two lines in my suphp.conf file to include quotes, which I did. But after restarting apache, I still get error 500. None of my files or directories are set to 777, so that's not the issue either. Does anybody else know what has changed in the newest suPHP release that would cause my config to no longer work? Thanks. Here is what my conf file looks like now:
[global]
;Path to logfile
logfile=/var/log/suphp.log
;Loglevel
loglevel=warn
;User Apache is running as
webserver_user=apache
;Path all scripts have to be in
docroot=/
;Path to chroot() to before executing script
;chroot=/mychroot
; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true
;Send minor error messages to browser
errors_to_browser=true
;PATH environment variable
env_path=/bin:/usr/bin
;Umask to set, specify in octal notation
umask=0022
; Minimum UID
min_uid=500
; Minimum GID
min_gid=500
; Use correct permissions for mod_userdir sites
handle_userdir=true
[handlers]
;Handler for php-scripts
;x-httpd-php=php:/usr/bin/php-cgi
php5-script="php:/usr/bin/php-cgi"
;Handler for CGI-scripts
x-suphp-cgi="execute:!self"
I am using atomic rocket turtle repos.
I fixed it. The following line is deprecated, so I just had to delete it:
handle_userdir=true