Fastcgi_index - am I missing something obvious?

Server NGINX
1

So I have the same setup on two different servers, using fcgiwrap to
serve some basic classic style cgi scripts.

On both,
http://serverdomain.whatever/cgi-bin/index.cgi works great
and other explicit .cgi urls work.
But only on one of them, http://serverdomain.whatever/cgi-bin/ takes me
to the index.cgi. On the other I get a 502.
What am I missing?
I think the unix permissions of /usr/lib, /usr/lib/cgi-bin and its
contents, and /var/www are the same on both servers.

The error log is

2014/10/15 11:16:40 [error] 30892#0: *845 upstream prematurely closed
FastCGI stdout while reading response header from upstream, client: [my
client ip], server: [my server adress], request: “GET /cgi-bin/
HTTP/1.1”, upstream: “fastcgi://unix:/var/run/fcgiwrap.socket:”, host:
“[my server adress]”

Sandra
Here is the conf:

server {
listen 80;

root /var/www/; # not really relevant
index index.html;

server_name my_server_name_went_here;

location / {
try_files $uri $uri/ /index.html;
}

this, as the rest of the conf, is the same on both

location /cgi-bin/ {
gzip off;
# the cgi-bin directory is in /usr/lib
root /usr/lib;
fastcgi_pass unix:/var/run/fcgiwrap.socket;
include /etc/nginx/fastcgi_params;
# this next line seems to work on one, not the other
fastcgi_index index.cgi;
fastcgi_param SCRIPT_FILENAME /usr/lib$fastcgi_script_name;
}
}

2

On Wed, Oct 15, 2014 at 01:17:49PM +0200, Sandra Snan wrote:

Hi there,

So I have the same setup on two different servers, using fcgiwrap to
serve some basic classic style cgi scripts.

Presumably the setups are only “nearly” the same, or else they would
respond the same way.

What version of fcgiwrap do you run on each server?

Can you show the output of “grep SCRIPT /etc/nginx/fastcgi_params”
on the servers? (One output is fine, if the two are identical.)

But only on one of them, http://serverdomain.whatever/cgi-bin/ takes me
to the index.cgi. On the other I get a 502.

What is the output of “curl -i http://serverdomain.whatever/cgi-bin/”,
especially on the failing server?

(That’s basically “have you cleared your browser cache?”, but is more
direct.)

What am I missing?
I think the unix permissions of /usr/lib, /usr/lib/cgi-bin and its
contents, and /var/www are the same on both servers.

Since a request for /cgi-bin/index.cgi succeeds, they almost certainly
are both correct; but the output of

ls -ldZ /
ls -ldZ /usr
ls -ldZ /usr/lib
ls -ldZ /usr/lib/cgi-bin
ls -lZ /usr/lib/cgi-bin/index.cgi

on each server should show that they are the same or not.

(Omit the Z if it shows errors.)

this, as the rest of the conf, is the same on both

If you “diff conf1 conf2”, do you see only and exactly the expected
changes from lines before this point?

Good luck with it,

f

Francis D. [email protected]

3

Thanks so much for finding so many avenues to trouble shoot, I had been
figuratively banging my head against the screen for hours, and all of
the ideas were good.

On Thu, 16 Oct 2014 00:02:11 +0100, Francis D. [email protected]
wrote:

Can you show the output of “grep SCRIPT /etc/nginx/fastcgi_params”
on the servers? (One output is fine, if the two are identical.)

This was the problem; the non-working server had a
fastcgi_param SCRIPT_FILENAME $request_filename;
line that I commented out, restarted nginx and now it’s working.
The working server was missing that line.
Both had a SCRIPT_NAME line, which I didn’t change.

So let that be a lesson to folks at home who find this post later!
I made a couple of mistakes here;

  1. assuming that the /etc/nginx/fastcgi_params files were the same; they
    plooked the same at first glance but I should’ve ran diff on them.
    Things usually are in one of the first places you look, if you don’t
    look carefully enough but think you have.
  2. assuming that a SCRIPT_FILENAME line in the included file would be
    harmless since I also had a
    fastcgi_param SCRIPT_FILENAME /usr/lib$fastcgi_script_name;
    line in the specific server conf, without doublechecking order of
    evaluation.

Readers with similar problems: if this doesn’t solve it, take a look at
the other suggestions.
Francis, thanks for taking the time to helping me troubleshoot this.
I was seriously stuck.

Sandra

4

On Thu, Oct 16, 2014 at 07:40:17AM +0200, Sandra Snan wrote:

On Thu, 16 Oct 2014 00:02:11 +0100, Francis D. [email protected] wrote:

Hi there,

Can you show the output of “grep SCRIPT /etc/nginx/fastcgi_params”
on the servers? (One output is fine, if the two are identical.)

This was the problem; the non-working server had a
fastcgi_param SCRIPT_FILENAME $request_filename;
line that I commented out, restarted nginx and now it’s working.

Good stuff. Any difference is a bad difference, when things should be
the same :wink:

The working server was missing that line.
Both had a SCRIPT_NAME line, which I didn’t change.

All of the fastcgi_param handling is pretty much down to the fastcgi
server, and different servers do different things, so there isn’t always
a single recipe that nginx can use.

  1. assuming that a SCRIPT_FILENAME line in the included file would be
    harmless since I also had a
    fastcgi_param SCRIPT_FILENAME /usr/lib$fastcgi_script_name;
    line in the specific server conf, without doublechecking order of
    evaluation.

That suggests that your current fastcgi server uses the first unique
fastcgi_param value that it receives. So if you had put the
fastcgi_param
line before the include line in your nginx config, you probably would
not have seen this problem (until something changed).

Francis, thanks for taking the time to helping me troubleshoot this.
I was seriously stuck.

Good to hear that it is resolved.

Cheers,

f

Francis D. [email protected]