Occasional FastCGI Error on Ubuntu 10.04

Discussion in 'General' started by GoremanX, Feb 13, 2011.

  1. GoremanX

    GoremanX New Member

    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:

    Code:
    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:

    Code:
    [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.
     
    Last edited: Feb 13, 2011
  2. till

    till Super Moderator Staff Member ISPConfig Developer

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

    GoremanX New Member

    Code:
    #!/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
    
     
  4. GoremanX

    GoremanX New Member

    erm... Hello?
     
  5. GoremanX

    GoremanX New Member

    seriously? 2+ weeks?
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  7. GoremanX

    GoremanX New Member

    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.
     
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  9. GoremanX

    GoremanX New Member

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

Share This Page