views:

186

answers:

1

Hi, I'm using nginx with this script as FastCGI wrapper, that I start with:

spawn-fcgi -F 3 -u www-data -s /var/run/perl-fcgi.sock -P /var/run/perl-fcgi.pid -- ./perl-fcgi.pl

Now, suppose I have a simple script:

#!/usr/bin/perl

print "Content-type: text/plain\r\n\r\n";
print "hello\n";

The script runs fine, and I see the "hello" when I request /text.pl. But as you can see in line 106 of the FastCGI wrapper, the script gets executed with exec(), so it basically runs in its own Perl environment. Doesn't it ruin the whole concept of FastCGI, when I don't have an already initialized script, but call it independently?

What would be the preferred way of interacting via FastCGI on nginx?

Cheers, --polemon

PS: spawn-fcgi is the program from lighttpd that starts FCGI wrappers and binds them to a socket.

+3  A: 

Yes, it ruins the whole concept of FCGI, but by design.

The script you're using is an FCGI to CGI adaptor, designed to work around ngnix' deliberate inability to serve CGI scripts.

To use FCGI "properly," just point ngnix at your FCGI-aware script. On the upside, if ngnix can talk to this FCGI-CGI adaptor, you know it can talk to another FCGI script. Specific server configuration is probably a question for serverfault.

pilcrow
The problem is, I'd like to use Perl as any other scripting language with nginx. I have working hooks for Lua and PHP, both run with FastCGI. If I'd run all other Perl scripts as I run the wrapper, I couldn't call any Perl application I like, I'd have to hook every Perl script with its own socket to nginx, which is not preferable.Is there no alternative?
polemon
@polemon, right. You need an FCGI broker or process manager, one which either spins up your individual scripts as long-running (FCGI) daemons, or which is itself the FCGI interpreter and can, say, dynamically compile stand-alone perl scripts into subroutines which then answer the request.
pilcrow
Schwern
Have you looked into PSGI/Plack ?
chiggsy