Occasional FastCGI Error on Ubuntu 10.04

[GoremanX]

Using the "Perfect Server" howto for Ubuntu 10.04 and ISPConfig 3.0.3.2

I've been trying to track down this error for weeks now, it's driving me nuts.

Every once in a while, site visitors using Firefox (on any OS) get the following error on the home page of the site:

Content Encoding Error

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

This only happens rarely (maybe once every 100 tries? I can't reproduce it reliably), and reloading the page fixes it right away. I wouldn't even mind so much if it wasn't always on the home page.

IE8 also gets hit with this problem, but instead of displaying an error page, it drops down to "compatibility mode" and renders the page horribly.

On the server, whenever this error page comes up, I get the following entry in the error log:

[Sat Feb 12 18:20:28 2011] [warn] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server, referer: http://www.friendlyphotozone.com/home/fpz-news?start=8
[Sat Feb 12 18:20:28 2011] [warn] (104)Connection reset by peer: mod_fcgid: ap_pass_brigade failed in handle_request function, referer: http://www.friendlyphotozone.com/home/fpz-news?start=8

I've tried looking this up everywhere I can think of, but can find no solution. It never happened on my old Ubuntu 9.10 server, but that one's long gone now.

What can I do to diagnose and solve this?

edit: I'm using the default wrapper script generated by ISPConfig to load fcgid.

[till]

Please post the content of the fcgi wrapper script that is used by this website.

[GoremanX]

#!/bin/sh
PHPRC="/etc/php5/cgi/"
export PHPRC
PHP_DOCUMENT_ROOT="/var/www/clients/client1/web1"
export PHP_DOCUMENT_ROOT
# The variable PHP_FCGI_CHILDREN is onyl useful for lighty or nginx as apache 
# mod_fcgi will control the number of childs themself and never use the additional processes.
# PHP_FCGI_CHILDREN=8
# export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /usr/bin/php-cgi \
 -d open_basedir="/var/www/clients/client1/web1/web:/var/www/clients/client1/web1/tmp:/var/www/clients/client1/web1/backup:/var/www/friendlyphotozone.com/web:/srv/www/friendlyphotozone.com/web:/usr/share/php5:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin" \
-d upload_tmp_dir=/var/www/clients/client1/web1/tmp \
-d session.save_path=/var/www/clients/client1/web1/tmp \
 $1

[GoremanX]

erm... Hello?

[GoremanX]

seriously? 2+ weeks?

[till]

The file is ok. The messages "Connection reset by peer: mod_fcgid" are logged when someone e.g. presses the cancel button in its browser while the page loads or when the connection is interrupted. So there is no problem on your server.

[GoremanX]

Originally Posted by till

The file is ok. The messages "Connection reset by peer: mod_fcgid" are logged when someone e.g. presses the cancel button in its browser while the page loads or when the connection is interrupted. So there is no problem on your server.

Actually this happened frequently to a lot of Firefox users, regardless if anyone was hitting Cancel or not.

According to the serverlogs, fcgid was hitting its end of life and getting restarted. Everytime that happened while a user was loading a page, they would get an error message in Firefox, or IE8 would drop into "compatibility mode". This happened multiple times a day to multiple users (including myself) at very random times. It was a very frequently-reported bug.

Uncommenting these two lines:

# PHP_FCGI_CHILDREN=8
# export PHP_FCGI_CHILDREN

and reloading the web server has finally fixed the problem. Now there's a running fcgid process waiting when an old one reaches EOL and gets shut own.

I needed to do this on every vhost, because each one suffered the same fate until that change was made.

[till]

These lines are already commented out in current ispconfig versions, as you can see in the master template and in the template the file that you posted above.

[GoremanX]

Originally Posted by till

These lines are already commented out in current ispconfig versions, as you can see in the master template and in the template the file that you posted above.

I said I UNcommented those lines and it fixed the problem.