Summary: It is not possible to run any of the simplest "Hello World" FastCGI scripts; any request always ends with a timeout. It seems that there is no connection at all between the server and FastCGI scripts (using dynamic FastCGI scripts).
Environment
- Ubuntu Precise (12.04)
apache2.2-bin packageapache2-mpm-preforklibapache2-mod-fastcgilibfcgi-perl packagepython-flup- Several sites configured as virtual hosts on
127.0.0.1 - There is a directory
/var/lib/apache2/fastcgi , owned by www-data , read by all (owner, group and others) - There is a directory
/var/lib/apache2/fastcgi/dynamic , owned by www-data , which is limited to the owner (readable, writable and only www-data ) - There is an inode / socket file in the directory
/var/lib/apache2/fastcgi/
Relevant FastCGI configurations:
The directory /etc/apache2/mods-enabled/ contains a link to fastcgi.conf and fastcgi.load ( mod_fastcgi included).
The fastcgi.conf file contains the following (left untouched, I did not edit it):
<IfModule mod_fastcgi.c> AddHandler fastcgi-script .fcgi #FastCgiWrapper /usr/lib/apache2/suexec FastCgiIpcDir /var/lib/apache2/fastcgi </IfModule>
The corresponding configuration file in /etc/apache2/sites-enabled/ contains the following (there is nothing more in the FastCGI setup):
<DirectoryMatch /fcgi-bin> Options +ExecCGI <FilesMatch "^[^\.]+$"> SetHandler fastcgi-script </FilesMatch> </DirectoryMatch>
Tested materials on a test virtual host:
There is fcgi-bin/test-perl.fcgi , the contents of which (a file executed by everyone and read by the owner and group):
#!/usr/bin/perl use CGI::Fast qw(:standard); $COUNTER = 0; while (new CGI::Fast) { print header; print start_html("Fast CGI Rocks"); print h1("Fast CGI Rocks"), "Invocation number ",b($COUNTER++), " PID ",b($$),".", hr; print end_html; }
There is fcgi-bin/test-python.fcgi , the contents of which (the file is executed by everyone and read by the owner and group):
#!/usr/bin/python def myapp(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return ['Hello World!\n'] try: from flup.server.fcgi import WSGIServer WSGIServer(myapp).run() except: import sys, traceback traceback.print_exc(file=open("errlog.txt","a"))
Problem
Although both fcgi-bin/test-perl.fcgi and fcgi-bin/test-python.fcgi start normally when executed from the command line, neither of them works when called, for example. like http://test.loc/fcgi-bin/test-perl.fcgi or http://test.loc/fcgi-bin/test-python.fcgi .
Nothing happens, and after some delay I get 500 error message, and Apache error logs contain several entries similar to:
[<date>] [error] [client <IP>] FastCGI: comm with (dynamic) server "/<…>/fcgi-bin/<script>.fcgi" aborted: (first read) idle timeout (30 sec), referer: <referrer> [<date>] [error] [client <IP>] FastCGI: incomplete headers (0 bytes) received from server "<…>/fcgi-bin/<script>.fcgi", referer: <referrer>
I spent hours and hours searching the Internet, trying to understand why it wasn’t working, and finally decided to refuse and ask for help here.
Any pointers and checklist are welcome. Feel free to ask about any missing details that may seem relevant or worth checking out to you.
Enjoy your pleasant day.
- change -
Release update
In my own answer to my question , I mentioned a strange case where everything looked unexpectedly for no reason. Later I discovered that it was only partly beautiful.
In the same virtual host, therefore, with the same server configuration, some scripts that are exactly the same (and with the same access rights) fail depending on their location.
As a remainder, here’s what’s in the site’s configuration:
<DirectoryMatch /fcgi-bin> Options +ExecCGI <FilesMatch "^[^\.]+$"> SetHandler fastcgi-script </FilesMatch> </DirectoryMatch>
In view of the above, only scripts in /fcgi-bin processed as FastCGI script. But I also have here and there (for testing): one in /cgi-bin and one in / (i.e. in the public_html directory). For this purpose .htaccess contains this entry:
Options +ExecCGI AddHandler fastcgi-script .fcgi
Thus, the other two FastCGI scripts should work the same as in /fcgi-bin , but they do not, and for a while they invariably end with a communication timeout, as one /fcgi-bin did at first.
This makes me feel like something might be wrong with the mod_fastcgi module (known bug? Else?). So far, this module has apparently acted in a rather random manner.
- edit 2 -
The above in the first edit was my mistake: the group was wrong with other scripts, it should have been www-data , but that is not the case. So something is wrong, stick to the answer that I gave, that is, try looking at FastCgiConfig and see if it solves something or, at least, if it observes the timeout parameters.