Forum: NGINX fcgiwrap upstream errors

Hello,

I'm still trying to get fcgiwrap to handle a hello, world perl cgi 
script.

I run:

spawn-fcgi -f /usr/local/bin/fcgiwrap -s /tmp/cgi.sock

The first time I try to pull up my cgi-bin/test.pl file, I get:

connect() to unix:/tmp/cgi.sock failed (13: Permission denied) while
connecting to upstream

Then I tried chmod o+w /tmp/cgi.sock

and then I get:

upstream closed prematurely FastCGI stdout while reading response header
from upstream

... I read most of the 42 results I got from querying the mailing list
about this error.... to no avail.

Any other suggestions?


Thanks,
Chris

On sob, lut 28, 2009 at 01:52:21 -0800, Chris Cortese wrote:
> Hello,

Hi,

> I'm still trying to get fcgiwrap to handle a hello, world perl cgi script.

Care to post it here? Maybe it's a simple missed/double newline or some
such?

> I run:
> 
> spawn-fcgi -f /usr/local/bin/fcgiwrap -s /tmp/cgi.sock
> 
> The first time I try to pull up my cgi-bin/test.pl file, I get:
> 
> connect() to unix:/tmp/cgi.sock failed (13: Permission denied) while 
> connecting to upstream
> 
> Then I tried chmod o+w /tmp/cgi.sock

Yes, the web server must have access to the socket.

> and then I get:
> 
> upstream closed prematurely FastCGI stdout while reading response header 
> from upstream
> 
> ... I read most of the 42 results I got from querying the mailing list 
> about this error.... to no avail.

Please update fcgiwrap (I have just pushed a new snapshot with possibly
better error reporting), and retry. If you get a 403 response, check 
your
Nginx error log (fcgiwrap got the request but declined to run it for
some reason). If it's still a 502, either Nginx is misconfigured, or
something is badly broken in your CGI script (a CR on the hashbang line
is one tricky mofo ;))

If it doesn't help, post the relevant parts of your config.

Best regards,
 Grzegorz Nosek

Grzegorz I don't know if you have enough time to whip up a quick perl
launcher that uses tcp like php-fpm commonly does and makes it easy to
say how many children you'd like? I don't know perl good enough or
trust my hacking skills for that. Of course then it would be even one
step closer to the solution we had talked about.

On Feb 28, 2009, at 4:04 AM,

On sob, lut 28, 2009 at 04:19:46 -0800, mike wrote:
> Grzegorz I don't know if you have enough time to whip up a quick perl  
> launcher that uses tcp like php-fpm commonly does and makes it easy to  
> say how many children you'd like? I don't know perl good enough or  
> trust my hacking skills for that. Of course then it would be even one  
> step closer to the solution we had talked about.

See my other reply.

Best regards,
 Grzegorz Nosek

I'll try the newer fcgiwrap when I get back home in a couple hours.  For
now, in case this is helpful info:

I'm getting a 403 Forbidden on the stdout of the terminal where I ran
the fcgiwrap.  At the same time I get

*11 upstream closed prematurely FastCGI stdout while reading response
header from upstream, client: my.ip.address, server: my_server, request:
"GET /cgi-bin/test.pl HTTP/1.1", upstream:
"fastcgi://unix:/tmp/cgi.sock:", host: "my_server:my_port"

in the nginx error log

and 502 Bad Gateway in the browser.

I have chmod 755 test.pl.  I took test.pl from the net somewhere.  It is
just:

#!/usr/bin/perl
print "Content-Type: text/html\n\n";
print "Hello, World!\n";

The relevant parts of my nginx config are:
in my_virtual_host.conf:

  location /cgi-bin/ {
    fastcgi_pass unix:/tmp/cgi.sock;
    include /etc/nginx/perl_fcgiwrap_params;
  }

in perl_fcgiwrap_params:  **note** I've tried a hundred different
variations on this but this is the current one:

        gzip off; #gzip makes scripts feel slower since they have to
complete before getting gzipped
        fastcgi_param QUERY_STRING     $query_string;
        fastcgi_param REQUEST_METHOD   $request_method;
        fastcgi_param CONTENT_TYPE     $content_type;
        fastcgi_param CONTENT_LENGTH   $content_length;
        fastcgi_param GATEWAY_INTERFACE  CGI/1.1;
        fastcgi_param SERVER_SOFTWARE    nginx;
#        fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
        fastcgi_param SCRIPT_FILENAME
/home/my_linux_user/www/dev/mysite/trunk/cgi-bin$fastcgi_script_name;
        fastcgi_param SCRIPT_NAME
/home/my_linux_user/www/dev/mysite/trunk/cgi-bin$fastcgi_script_name;
        fastcgi_param REQUEST_URI        $request_uri;
        fastcgi_param DOCUMENT_URI       $document_uri;
        fastcgi_param DOCUMENT_ROOT      $document_root;
        fastcgi_param SERVER_PROTOCOL    $server_protocol;
        fastcgi_param REMOTE_ADDR        $remote_addr;
        fastcgi_param REMOTE_PORT        $remote_port;
        fastcgi_param SERVER_ADDR        $server_addr;
        fastcgi_param SERVER_PORT        $server_port;
        fastcgi_param SERVER_NAME        $server_name;

... and just to reiterate, everything else on my site is working great,
php, rewrites, everything else working as far as I can tell.


Thanks,
Chris

Try inserting:

chmod 0666, $socket_path;

after

die "Cannot create socket at $socket_path: $!\n" unless $socket;

Jim

The new fcgiwrap is interesting, thanks.

No more 502 bad gateway, the browser now says simply "403" (the error I
was getting on stdout already).

The new nginx error log msg is better too, although I still haven't
solved this problem.  Here it is:

27211#0: *33 FastCGI sent in stderr: "Cannot get script name, is
DOCUMENT_ROOT and SCRIPT_NAME set and is the script executable?" while
reading response header from upstream, client: .. etc ...

Script is executable by all.

The relevant parts of config are:

fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SCRIPT_NAME /full/path/to/my/cgi-bin$fastcgi_script_name;

Note that my cgi-bin is higher up in the directory tree than my web
document root.  Surely this is not a problem??  In Apache, this is
accomplished with ServerAlias directive.

Also I notice on this page that the document_root must end in a slash.
http://wiki.codemongers.com/NginxSimpleCGI  ... unclear how to know if
that's part of my problem...


Chris

I have resolved my problem and can now see my hello, world script!  The
final fix for me was I had to put the "root" directive inside my
location /cgi-bin/ {} block.

I can't test my real script yet because I hit a new problem.  For some
reason, I am not getting my $_POST variables.  I have to login to the
site (and use $_POST) to hit my real cgi script.  This was working fine
yesterday so it's probably something simple.

well remember, $_POST is PHP only afaik.

you have to access it other ways in Perl/CGI

On Sat, Feb 28, 2009 at 10:52 PM, Chris Cortese