mod_fcgid read data timeout - Premature end of script headers - php

The websites on one of my Plesk users can't be accessed. The server reports a 500 Internal server error, the error_log for that user shows a bunch of
[warn] mod_fcgid: read data timeout in 60 seconds
[error] Premature end of script headers: index.php
The DocumentRoot contains a normal WordPress installation. Other sites running the same WP version, using the same DB server and PHP+Extensions run fine. A <?php phpinfo(); ?> runs fine as well. Calling php index.php from cli returns the webpage, but is a bit too slow for an idle Xeon E5-2620 Server w/ 64GB RAM
Are there any known Problems? How can I debug further?
Some more system info:
PHP 5.6.24 (tried 5.4 as well)
Plesk 12.5.30
EDIT: The Problem occurs intermittently. Right now, no 500 Error is returned, site loads fine (a bit slow). I increased memory_limit, just to be sure it isn't a config limitation

You can try to increase FcgidIOTimeout as described here https://kb.plesk.com/en/121251
Since Plesk 11.5, "FcgidIOTimeout" parameter is set to the same value as max_execution_time php parameter in domain's PHP settings
Also you can try any of PHP-FPM handler instead of FastCGI, because of mod_fcgid has a lot of internal performance limitations which can't be avoided.

The problem was caused by a rogue file_get_contents in some scripts.
I looked through the error log for the 1st appearance of the error message, and found a file created exactly when the error message first appeared - only 2 years earlier...
WordPress Site hacked? Suspicious PHP file
So I removed the malware ( detailed write-up at https://talk.plesk.com/threads/debugging-premature-end-of-script-headers.338956/ ), rebooted the Server and the error is now gone.
Technical detail: The error turned up because the Server distributing the malware is offline. file_get_contents("http..." timed out, the local script failed and returned the error message.

Related

Absurdly high memory allocations with php7.4 under apache windows

What could be the cause of these very unlikely high memory allocations attempts, I notice lately on my production server:
PHP Fatal error: Allowed memory size of 1006632960 bytes exhausted (tried to allocate 51002234388 bytes) in D:\wp\wp-includes\load.php on line 1466
This happened in Wordpress (see error message), but also in Lime Survey.
I'm running PHP 7.4.27 on Windows Apache 2.4.21 on a Windows Server 2008.
The error is consistent (same number of bytes, same script, same line) and remains after a server restart.
Strangely I could get rid of the error in a Lime Survey installation by simply moving all the script files to a different folder.
Edit: Same now: Downloading via FTP all the script files in D:\wp, creating a new directory D:\wp and uploading all the files fia FTP, the error vanished. What's going on here?
Thank you!
The cause is most likely plugin related.
I would check:
wordpress error logs
php error logs
Apache error logs
server error logs
any pending cron jobs.
isolate and debug any plugin DB queries.
are there any heavy reports (DB generated)
Isolating which plugin, can be done by using a live backup, and deleting/disabling plugins one at a time.
Increasing the memory limit may be done through wordpress, but may not bite, unless configured on the server or php level.
1 - check PHP 7.4 memory limit
(check php.ini -- check folder configuration
in the windows)
2 - Insert memory limit in wp-config.php
3- insert the memory limit in .htaccess
4 - Check the plugins.
5 - Possibly have a hidden malicious code file
( 5.1 - look for files with the same name as the folder. Example: FOLDER = theme (when entering the folder) there is a file with the name = .theme.php
5.2 - Analyze your index.php, wp-config.php or .htaccess (if they were not auterated, enter codes)
6 - Analyze the logs
Now, after a while I strongly guess it was the opcache functionality, that caused the error. Maybe after updating some of the scripts did conflict with left untouched ones in the opcache.
Turning off the opcache did the trick (till now :)).

HTTP 500 – Wordpress WP-API without any message?

I'm using themosis – a framework for wordpress that works pretty well. Also I use WP-API - that doesn't work so great.
All versions are the latest stables and the Server is using PHP 5.5
On calling that API route:
posts?filter[order]=ASC&filter[orderby]=name&filter[posts_per_page]=-1&type=products
I'm getting an Internal Server error / HTTP 500
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, webmaster#example.ch and
inform them of the time the error occurred, and anything you might
have done that may have caused the error.
More information about this error may be available in the server error
log.
So my hoster checked the logs and the only lines caused by this error were:
[Tue Jul 07 17:43:13 2015] [error] Premature end of script headers: php55-fcgi-starter.fcgi, referer: {myurl/mypath}
I checked all log, forced everything to display errors & logs, but no PHP errors - not even notices... (set display_errors to On and error_reporting to 2039 - with htaccess and php-side (wordpress index.php)
I just figured out that when I set the post_per_page filter is set to e.g. 90 it works, but only till a specific post.
All posts are "normal" - making a WP_Query also delivers all results without any issues.
I also increased the php memory_limit to more than enough and tested it locally (Mac OS / MAMP) what works great.
I really can't find any reason why this is happening. My server hoster support (which is really good actually) says also that all systems run fine

imagefill() causing 'Premature end of script headers'

I'm posting because after hours of searching I'm utterly confounded. Here's the deal. My Laravel application uses the PHP Image Workshop bundle. Everything seems to be working fine, except if I try to make a resizeInPixel() call or a cropInPixel() call (or similar calls) the server throws an internal server error. If I investigate the error log I see:
Premature end of script headers: index.php
This only occurs when I use the resize and crop related methods (i.e. image processing). I can initFromPath() with no issue, and I can use the save() method without issue. Only the image processing methods cause the internal server error.
I've also read online that this can be the result of a suphp_log file exceeding 2GB. I've tracked down and cleaned out that file, but to no avail.
Any thoughts are most welcome! Even if they're just general "have you tried...".
UPDATE
I've narrowed it down to a particular line in the Image Workshop code. This line is causing the error:
imagefill($image, 0, 0, $color);
Additionally, this error only occurs when the color is created using imagecolorallocatealpha, NOT when it is created using only imagecolorallocate.
There are some great hints for solving this issue at Liquidweb.com. My money is on #2 (see bold text) because you are getting the error when doing image manipulations:
Sometimes when executing a script you will see an error similar to the following:
Premature end of script headers: /home/directory/public_html/index.php
This error occurs because the server is expecting a complete set of HTTP headers (one or more followed by a blank line), and it doesn’t get them. This can be caused by several things:
Upgrading or downgrading to a different version of PHP can leave residual options in the httpd.conf. Check the current version of PHP using php -v on the command line and search for any lines mentioning another version in the httpd.conf. If you find them, comment them out, distill the httpd.conf and restart apache.
The RLimitCPU and RLimitMEM directives in the httpd.conf may also be responsible for the error if a script was killed due to a resource limit.
A configuration problem in suEXEC, mod_perl, or another third party module can often interfere with the execution of scripts and cause the error. If these are the cause, additional information relating to specifics will be found in the apache error_log.
If suphp’s log reaches 2GB in size or larger you may see the premature end of scripts headers error. See what the log contains and either gzip it or null it. Restart apache and then deal with any issues that the suphp log brought to light. The suphp log is located at: /usr/local/apache/logs/suphp_log
The script’s permissions may also cause this error. CGI scripts can only access resources allowed for the User and Group specified in the httpd.conf. In this case, the error may simply be pointing out that an unauthorized user is attempting to access a script.
UPDATE:
After some more info in the comments, I still feel this is a memory related thing.
According to this SO wiki: About gdlib
Warning: Image functions are very memory intensive. Be sure to set memory_limit high enough
What is your PHP memory_limit? Can you crank it up a bit?

Magento: Getting 500 internal server error when creating invoices

I'm facing a big problem with my current Magento Shop. When I create an invoice through the backend I'm getting an 500 internal server error (after a long loading process). The server logs dont show anything, I looked into /var/log/apache2/error.log and theres nothing related. The error didnt show up on my dev machine, but since I moved the shop to our live server it occurs all the time.
What I tried so far:
Checked the file and folder permissions
Enabled Mage::setIsDeveloperMode(true); and ini_set('display_errors', 1);
Still no errors or logs
Deleted local.xml and generated a new one
Increased memory limit
Increased max execution time
Cleared cache
Checked .htaccess file, everything seems fine
Ran a script to check if everything matches the Magento requirements
This is starting to keep my busy for a couple of days now... and I dont know where to start, because the server doesnt even output an error in the logs. How can I force the server to log the error in the according file?
Do you have any other ideas what I can try to get rid of the error?
Attached also my php.ini file, maybe that helps.
PHP.ini http://pastebin.com/9BWQRHTu
PHP Version and OS: PHP Version 5.3.2-1ubuntu4.21
Env: Virtual Private Server
Increase memory_limit from 128M to 256M or 512M.
Clear browser cache and cookies. Do you encounter the same "500 server error" in other browser?
You said the loading process is long - measure the exact time couple of times and if the time is the same, which is set in php.ini, increase the max_execution_time
Find why is it taking so long to create an invoice using a debugger - most probably some module you have installed has a problem, like infinite loop, or it might trigger an action, which takes a lot of time, for example, reindexes everything each time. Creating an invoice shouldn't take so long and it is a problem in code - not in server settings probably.
I looked into the wrong error_log file, as I'm using Plesk the correct error_log file was located in /var/www/vhosts/xxx.com/statistics/logs/ and not in /var/log/apache2/
The error in there was
[Mon Nov 04 14:37:13 2013] [warn] [client xxx] mod_fcgid: read data timeout in 45 seconds, referer
This lead me to the fcgid.conf (etc/apache2/mods-available/fcgid.conf) where I had to increase the following values:
FcgidIdleTimeout 3600
FcgidProcessLifeTime 7200
FcgidMaxProcesses 64
FcgidMaxProcessesPerClass 8
FcgidMinProcessesPerClass 0
FcgidConnectTimeout 300
FcgidIOTimeout 180
FcgidInitialEnv RAILS_ENV production
FcgidIdleScanInterval 10

How to recover crashed Symfony App due to PHP error? PHP 5.3.1 / Apache 2.2.14

I am getting this strange error on PHP 5.3.1 on Apache 2.2.14. I went thru the forums and most suspect it is a PHP-issue memory-leak issue. WHile I upgrade PHP, I wanted to know if there is a way for the server to recover - to be restarted programatically. Currently, I have to manually start-stop Apaache
Warning: Attempt to assign property of non-object in D:\xampp_ext\xampp\htdocs\soki\test.soki.com\symfony\lib\autoload\sfCoreAutoload.class.php on line 38
Warning: require(/config/sfProjectConfiguration.class.php) [function.require]: failed to open stream: No such file or directory in D:\xampp_ext\xampp\htdocs\soki\test.soki.com\symfony\lib\autoload\sfCoreAutoload.class.php on line 99
Fatal error: require() [function.require]: Failed opening required '/config/sfProjectConfiguration.class.php' (include_path='.;d:\xampp_ext\xampp\php\PEAR') in D:\xampp_ext\xampp\htdocs\soki\test.soki.com\symfony\lib\autoload\sfCoreAutoload.class.php on line 99
I'm using PHP 5.3.1 on Apache 2.2.14
PHP is run by Apache, so if Apache has indeed crashed, you can't easily use PHP to start Apache again unless PHP is being called by some other program besides Apache (example: running PHP as a cron job/scheduled task by calling PHP.exe [script.php] directly).
I'm assuming by the path in your error message that you're using a Windows environment (obviously). You don't want a script or program in the background starting Apache over and over if the process isn't running; that's messy. You could but that is nowhere near ideal.
How do you even know Apache is crashing? The errors you provided are errors from PHP, not Apache. If you refresh the page and still see errors (or anything besides a Connection Failure/Forcefully rejected/etc.) then Apache is still running.
Double-check that Apache is indeed no longer running
Check error logs in Apache's logs folder
Report back with your findings
Assuming that you are using mod_php requires to work with the Apache prefork worker model. There is a configuration setting you can use to implement a work-around:
With the MaxRequestsPerChild directive you can set a number of requests that will be processed before child processes will be recycled. Workaround: Put it to a low value, so that Apache will recycle it's children more often.
<IfModule prefork.c>
StartServers 2
MinSpareServers 3
MaxSpareServers 3
ServerLimit 30
MaxClients 30
MaxRequestsPerChild 200
</IfModule>
Please keep in mind that this is only a dirty hack and not a serious solution of your problem.
I read jillions of blog posts about the error, and my best option was to upgrade to PHP 5.3 and that resolved the problem. It was definitely due to a memory leak somewhere that was preventing additional files to be loaded

Categories