Problem Description
- You receive a 500 error.
- Logs might say: Premature end of script headers
- Logs might say: Connection reset by peer: mod_fcgid: error reading data from FastCGI server
- Logs might say: Allowed memory size of xxxxxxxx bytes exhausted. Solution for this specific error here.
Problem Resolution
In most cases additional details about the error will be shown when you follow this guide to reading and interpreting logs using Plesk. If you're not seeing a more specific error around the same time (within 3 seconds) as the 500 error, then continue with these possible options:
1. Problems with .htaccess
Disallowed Options: The most common version of this is having FollowSymLinks in one or more .htaccess files. Check the logs, as shown above, to learn which .htaccess file has the directive, and comment it out by placing a # at the start of the line that contains FollowSymLinks (or +FollowSymLinks).
SymLinks are disabled in shared hosting environments as they are commonly used as a medium to attack other websites hosted on the server. If you have your own VPS, FollowSymLinks can be enabled.
Redirect Problems: If you have a redirect in .htaccess that forces HTTPS or www (or no-www) but you also have these options enabled in Plesk, the redirects can conflict, creating endless loops and possibly server errors in the process.
Ensure that you're using the Plesk options under "Hosting Settings" to set your "Preferred domain" and "Permanent SEO-safe 301 redirect from HTTP to HTTPS" and remove the redirect from .htaccess.
2. Problems with cloning, backups, or restores from backup
This is most often caused by a security plugin, like WordFence, attempting to load a particular file (like .user.ini) and failing to do so because the file hasn't yet been copied over or restored from backup. You should use the link above to find the actual log entry that corresponds with the error. it will show you which file is causing the problem so that you can rename it or remove it to get things working again. Here's an example of this in action:
mod_fcgid: stderr: PHP Fatal error: Unknown: Failed opening required '/home/username/domain.com/wordfence-waf.php' (include_path='.:/opt/plesk/php/7.0/share/pear') in Unknown on line 0
In this instance the hidden file called '.user.ini' found in the web root is attempting to load wordfence-waf.php from a non-existent location. Your best bet is to delete the .user.ini file or rename it to simply user.ini.bak to disable it. If you get a different filename/path, you probably just need to correct the path to solve the problem.
3. PHP and File Permissions
Your PHP Settings in Plesk are set to Apache Module mode and the wp-config.php file (or other core file) does not have 'other' read permissions
Please do not change the permissions -- wp-config.php is intended to have limited permissions to ensure optimal security of your website. Instead, change the PHP run mode to either FPM or FastCGI.
4. You receive a 500 error when working with Perl / CGI
If you have just uploaded the file via FTP:
Make sure your FTP app is configured to upload scripts in ASCII mode, not binary. If your FTP program is set to "auto-detect," make sure that the file type (.cgi or .pl) of the script is on the list of ASCII file types.
Verify Plesk web server configuration:
Login to Plesk and go to the "Apache & nginx Settings" for the domain. Ensure Proxy mode, Smart static files processing, and Serve static files directly by nginx are all enabled. This is also optimal for performance and nginx handles all static files faster, while passing cgi/perl through to apache.
Verify folder and file permissons:
Make sure the permissions the webroot folder are correct. You can verify these values and make all necessary changes with the Plesk File Manager as described here or with your FTP app and/or using SSH/shell (helpful commands below).
- All folders/dirs within web root must have permissions set to 755
- All executable Files (.cgi, .pl) must have permissions set to: 740
- All non-executable Files (javascript, html, images, etc) must have permissions set to: 644
For those that prefer shell you can run the following commands to adjust every file and folder for the site at once.
IMPORTANT: do not run these commands from within the user root. You must cd into the web root directory where the website's executable files reside. This is httpdocs for the primary domain, typically the domain name for an addon domain. The web root directory for each domain is shown in Plesk.
cd <WEB_ROOT_DIR>
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
find . -name '*.cgi' -exec chmod 740 {} +
find . -name '*.pl' -exec chmod 740 {} +Verify folder and file ownership (this is usually correct by default):
All files and folders must be owned by your account username and the group psacln. You can run this via shell to ensure this is the case:
chown -r <PUT_USERNAME_HERE>:psacln *
Verify the Perl Path:
Make sure that the path you are using for PERL in your cgi scripts is correct. The correct first line of your perl scripts should be: #!/usr/bin/perl
If you are using: #!/usr/bin/perl -w ; this is good for trouble shooting your code, but should be removed when you upload your files for public viewing. The -w option is to display warnings that your script outputs. If your script has warnings than you will get a 500 error every time, since it's displaying the warnings first, causing the premature end of script headers.
Check for Syntax Errors:
if the code is broken or incomplete then it will return a premature end of script headers (500 error) PLUS another error indicating where in the file the script is failing to run. Find the code it's referring to in order to fix this. You will need a Perl developer if you are not one.
5. Actual server problem
The simple version: try running plesk repair web -- it might fix this for you.
If the logs don't indicate any specific issue and none of the above solve the problem, you will need root access to the server to continue. If you're on shared hosting or have a Platium managed server, ask us to look into this part for you.
The next step is to trace the generic error that you're seeing in the vhost-specific logs to the server-wide web server logs. Check /var/log/httpd/error_log and you will probably see some kind of additional error like this:
[error] mod_fcgid: process /var/www/cgi-bin/cgi_wrapper/cgi_wrapper(20820) exit(communication error), get unexpected signal 11
This indicates some kind of misconfiguration that needs to be tracked down. This particular error was generated when two PHP modules conflicted. The issue was reported to the developer to get it fixed, and the module was commented out.
