FCGI app reloading on every request - solved
nagle at animats.com
Wed Sep 5 17:25:05 CEST 2007
Sion Arrowsmith wrote:
> John Nagle <nagle at animats.com> wrote:
>> Tried putting this in the .htaccess file:
>>allow from all
>>ErrorDocument 403 "File type not supported."
>> Even with that, a ".foo" file gets executed as a CGI script,
>>and so does a ".fcgi" file. It's an Apache configuration problem.
> I'd look to see if you've got a AllowOverride None set somewhere
> unhelpful (probably on the cgi-bin directory, although I note the
> default Apache2 config on my machine here does it for the document
> root too). Mind you, if you're managing this with a web tool rather
> than having access to the Apache config files, it might not be so
> straightforward to do.
I now know what's wrong; it's a combination of several problems.
First, configuring Apache via Plesk has very limited options,
and no documentation telling you what it's doing. The actual
problem is that Plesk generates, in "/etc/conf/httpd.conf".
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
This makes anything in cgi-bin executable with mod-cgi,
regardless of anything set up for any other suffix. For
historical reasons, CGI gets better treatment in Apache than
other "mod-" components, and apparently ScriptAlias outranks
Files and AddHandler. So that's why .fcgi programs were being
run as .cgi programs.
With the Plesk-created configuration, an executable ".fcgi" file
in any web-server-visible directory OTHER than "cgi-bin" will execute
with mod_fcgi. So that's how to get around this. Note that this is
backwards from the usual CGI configuration, where scripts will execute
only from "cgi-bin". This has security implications.
If you're using Plesk, you can't change the defaults, because Plesk
regenerates the config files when you use the Plesk control panel app.
Nor will overrides in .htaccess work; those are disallowed by an
"AllowOverride None". So you're stuck with what Plesk gives you.
Even on a dedicated server using Plesk.
Then there's mod_fcgid, which Plesk configures but has almost no
documentation either. If mod_fcgid can't spawn an application
process, for any reason, including a simple Python error,
the error message is "[warn] mod_fcgid: can't apply process slot for ...".
That's all you get in the Apache log. The web user gets "Service
Temporarily Unavailable", because mod_fcgid doesn't distinguish
internally between "don't have enough resources to spawn a new process"
and "new process didn't launch correctly". I had to look at the
source code for mod_fcgid to figure out what it meant. (Ruby on Rails
people get this message now and then, and they're puzzled by it.)
So that's what's going on. This sort of thing is why mod_fcgid,
which is actually a good concept, isn't used much.
More information about the Python-list