Description
The 500 Internal Server Error is a “catch-all” server error and the server cannot be more specific about the nature of the error. The causes for a 500 error can be any number of things and about 9/10 times the error comes from a code error, which means that the problem is not necessarily the server having problems but rather the server having a problem with the coding of a web application.
Troubleshooting to Fix
Wait for one minute and try reloading. If the server does not reload the page then you will need to dig deeper to find a solution to the 500 internal server error.
TIP: Always check the error logs, you can usually find which of the following is causing the error. Look at all the logs relevant to your site. I.E. If your web application uses php then check the php error_log located in the folder of the php program. When checking the webhosting daemon error logs try and search for your ip address in order to show the daemon’s error for that webpage you are receiving the 500 internal server error.
General Guidelines
- One or more folder does not have 755 permissions or the file that you are browsing has file permissions above 755.
- A php.ini has some settings that are broken or entries that are not compatible with our servers.
- You have too many processes running at the moment that it occurred. (You remembered to check the process manager, right?)
- If you are running Perl or Python scripts the files need to have 0755 permissions as well as not have ^M characters at the end of the lines in the file, if the file was not compiled. (If the file have 0644 permissions it will give you a 500 error if it is using Perl, Python, or Ruby.)
- Password protected directories causing issues. (You can tell it is this issue if the 500 error goes away once you remove the password protection.)
- If you are running the maximum amount of allowed processes you will receive a 500 error. If you are using persistent mySQL connections that can cause the scripts to not die as they are supposed to.
Remember to check the process manager if you don’t want to look in SSH how many processes are running.
This will kill all processes for the user that are running on the ramdisk
ps aux | grep `whoami` | grep ramdisk | awk '{ print $2 }' | xargs -i kill -9 {};
This command will kill php processes
killall -9 php php4 php5
FastCGI & the temporary URL.
- If they are using FastCGI & they are not using the domain name it will cause 500 errors. They will need to point the DNS to us to use it & also use a domain name in the URL or stop using FastCGI. Please note that Magento does not work with FastCGI turned on.
- If you uploaded a file that is encoded as ASCII instead of binary. (Some of the encoders I’m referring to are Zend Guard, IonCube, SourceGuardian, & phpSHIELD)
.htaccess file
- two entries on the same line of the .htaccess file that are supposed to be on one line.
- Attempting to make changes to php settings in the .htaccess file will cause a 500 error.
- Check for any other invalid entries in the .htaccess file it can cause the issue.
Perl or Python issues
- If it is a file that is running Perl or Python the file needs to have 0755 permissions.
- If the script is not compiled you can run dos2unix on the file.
Upload the file again as binary instead if the files are compiled or have something that was encodes by a program like one of the following Zend Guard, IonCube, SourceGuardian, & phpSHIELD.
- If the file is not compiled it needs to not have files that end with the “^M” character. The cause for the “^M” character is if they edited the file on a Windows computer & uploaded the file in binary mode.
- Running CGI/Perl outside the cgi-bin folder. This really depends on how the webhost server is configured. Some servers allow for running CGI/Perl scripts outside the cgi-bin folder. You need to add the following line to the .htaccess file in that directory:
Options ExecCGI
An additional line is often seen together with this, but should not be needed if you’re getting as far as 500 errors, as without it, the contents of the file will be served directly to the browser:
AddHandler cgi-script .<extension>
- Missing the appropriate shebang. The shebang line tells Linux what interpretor to use for a script. If you do not have that line, the script will fail to execute, causing a 500 error.
Common shebang lines:
perl
#!/usr/bin/perl
#!/ramdisk/bin/perl
#!/usr/bin/env perl
python
#!/usr/bin/python
#!/usr/bin/python2.4
#!/usr/bin/python2.6
#!/ramdisk/bin/python
#!/usr/bin/env python
ruby
#!/usr/bin/ruby
#!/ramdisk/bin/ruby
- Make sure the syntax is correct. This can be done for perl and python through the following respectively.
perl -c testing_file.cgi
python -c testing_file2.py
PHP common errors
- Make sure the syntax is correct. Simply missing a “;” at the end of a line will cause the server to through a 500 error. Check your php code by running the following command:
php -l somefile.php
- Check the error_log. This will help solve 90% of all problems by learning how to debug erroneous code.
Rails 2.0.2
Rails 2.0.2 brings a new round of things that can go wrong. Start with these first, then move onto the fixes we previously supplied for 1.2.6.
500 Internal Server Error
A common reason for this error with Rails 2.0.2 has to do with the way it wants to handle cookie session data. To confirm this is the problem, check ./config/environment.rb to see which environment is active, then check ./log/development.log or ./log/production.log as the case may be for an error such as this one (may have to scroll up a page or two from the bottom)…
/! FAILSAFE /! Sat Feb 09 10:53:30 -0700 2008
Status: 500 Internal Server Error
A secret is required to generate an integrity hash for cookie session data. Use
config.action_controller.session = { :session_key => "_myapp_session", :secret =>
"some secret phrase of at least 30 characters" } in config/environment.rb
If you too have this error, just do what it says, but don’t put it just anywhere in config/environment.rb, put it somewhere between Rails::Initializer.run do |config| and its matching end line. For example…
Rails::Initializer.run do |config|
# Settings in config/environments/* take precedence over those specified here
# Skip frameworks you're not going to use (only works if using vendor/rails)
# config.frameworks -= [ :action_web_service, :action_mailer ]
# Only load the plugins named here, by default all plugins in vendor/plugins are loaded
# config.plugins = %W( exception_notification ssl_requirement )
# Add additional load paths for your own custom dirs
# config.load_paths += %W( #{RAILS_ROOT}/extras )
# Force all environments to use the same logger level
# (by default production uses :info, the others :debug)
# config.log_level = :debug
# Use the database for sessions instead of the file system
# (create the session table with 'rake db:sessions:create')
# config.action_controller.session_store = :active_record_store
# Use SQL instead of Active Record's schema dumper when creating the test database.
# This is necessary if your schema can't be completely dumped by the schema dumper,
# like if you have constraints or database-specific column types
# config.active_record.schema_format = :sql
# Activate observers that should always be running
# config.active_record.observers = :cacher, :garbage_collector
# Make Active Record use UTC-base instead of local time
# config.active_record.default_timezone = :utc
# Add new inflection rules using the following format
# (all these examples are active by default):
# Inflector.inflections do |inflect|
# inflect.plural /^(ox)$/i, '1en'
# inflect.singular /^(ox)en/i, '1'
# inflect.irregular 'person', 'people'
# inflect.uncountable %w( fish sheep )
# end
# See Rails::Configuration for more options
config.action_controller.session = { :session_key => "_myapp_session", :secret => "123456789012345678901234567890" }
end
