Why are you getting 500 internal server error on your php pages

Usually this happens in a suPHP environment. There could be few reasons why this could happen. We list here a few. The solution is intended for those with shell access.

• Ownership issues
  In a suPHP environment, depending on the mode of suPHP enabled on the VPS or server, there is a min_uid setting, which is configurable in suPHP.conf under /etc or /usr/local/etc or /opt/suphp/etc . By default the setting is 100, which means if the file is owned by a UID less than that value (100), it shouldn’t parse the php code and will result in 500 Internal Server Error. In a cPanel server, the error will be shown @ /usr/local/apache/logs/suphp.log. This restriction would enable better security, since even if a php can do some privilege escalation, it wont affect the server. Solution would be

  chown your_username.your_username path_of_your_php_file

  If that fixes only that file and not your entire php files, use the below command to change all the php files.

  find . -type f -name “*.php” -exec chown username.username {} \;
  find . -type d -exec chown username.username {} \;

  Ignore “*.php” in the above command if it still errors out for a php file. If it still don’t fix, move on to other solutions below.

• Permission issues
  It could be the world writable directories or files which is causing the issue. In a non-suphp environment, if a php script has to upload a file on a folder, (eg:  php based gallery script where customers are able to upload photos) inorder to get it uploaded to the folder, it needs to have world writable permissions. Or else apache can’t write to the folder. Here in suPHP, since the php is executed as the user itself who already have the permissions you don’t need to change it to 777 permissions and is happy with 755 (rwxr-xr-x) permissions. When a customer is moved from a non suPHP env to suPHP enabled server, we need to adjust the permissions then. Often a command like below should help

  find . -name “*.php” -type f -exec chmod 644 {} \;
  find . -type d -exec chmod 755 {} \;

  Often, you can do the above command without the -name “*.php” in the command.

• suphp.log exceeds 2GB size.If the entire servers’ php application gives you internal server error, next chance is that the suPHP log has exceeded 2GB space. Just clear the file and you are on track again. To null it, execute the command below. Below command assumes you are having the issue in a cPanel server
  

  cat /dev/null > /usr/local/apache/logs/error_log

• suPHP log don’t exist
  In a Plesk or Webmin or other servers, often the suPHP will be installed but /var/log/httpd or such folders where the suPHP.log can be created wont exist. suphp can understand and create a non-existent suphp.log, but you would need to manually create the folder /var/log/httpd. I hope you know how to create a folder though.

If you know any other cases which require another solution for this, please comment here or edit the blog.

Internal server errors while accessing Fantastico and phpmyadmin in cPanel & WHM

Not a common issue. But sometimes this happens. If you have noticed, when you are logged into cPanel or WHM using the root password, you wont be able to install Fantastico applications or access MySQL DBs using phpmyAdmin. Most of the times, the error occurs will be similar to below

Internal Server Error

Premature end of script headers: php: Please check /usr/local/cpanel/logs/error_log for the exact error.

So far, the solution of this issue didn’t get complicated and a simple recompilation of cPanel PHP used to solve the error. To recompile cPanel PHP, issue the command below

/scripts/makecpphp

This would make sure that cPanel PHP, suPHP and other permissions will get set properly. Good luck.