Actually, it will process one request for each process and die right
after…
FastCGI: manager (pid 11232): server (pid 11233) exited with status 2304
FastCGI: manager (pid 11232): sending TERM to PIDs, 11237 11235 11236
11234
FastCGI: manager (pid 11232): server (pid 11235) exited with status 0
FastCGI: manager (pid 11232): server (pid 11236) exited with status 0
FastCGI: manager (pid 11232): server (pid 11237) exited with status 0
FastCGI: manager (pid 11232): server (pid 11234) exited with status 0
FastCGI: manager (pid 11232): dying: calling process has died
Not to mention it’s not persistent. Anyone have any better tools to
keep Perl-capable fastcgi engines running?
One option is to use the start script that comes with lighttpd.
Personally, I just write my perl applications to talk to the FastCGI
server
themselves, using FCGI::Async. And I use daemontools (see http://cr.yp.to/) to
keep them running.
To implement real FastCGI servers in Perl, you can use the CGI::Fast
module.
For process management, supervisord (http://supervisord.org/) can manage
any
kind of FastCGI processes. The FastCGI support has not been officially
released yet but if you check out the trunk, it will work just fine.
The
config would look something like this.
I would prefer not to have FastCGI needed. So - is there a simple way
to get nginx to execute .cgi / .pl / etc perl scripts itself? or some
easy hack like that?
Not to mention it’s not persistent. Anyone have any better tools to
keep Perl-capable fastcgi engines running?
That page has nothing to do with running Perl FastCGI scripts. It’s a
hack to allow CGI scripts to run as FastCGI (which is why it’s not
persistent… CGI scripts don’t expect to be persistent).
Not to mention it’s not persistent. Anyone have any better tools to
keep Perl-capable fastcgi engines running?
One option is to use the start script that comes with lighttpd.
Personally, I just write my perl applications to talk to the FastCGI server
themselves, using FCGI::Async. And I use daemontools (see http://cr.yp.to/) to
keep them running.
yeah… i tried to use upstart (ubuntu’s init replacement) since it’s
already available to me but i can’t keep the scripts to persist, i
don’t think the example script on the wiki returns the appropriate
return codes for a persistent thing like that.
yeah… i tried to use upstart (ubuntu’s init replacement) since it’s
already available to me but i can’t keep the scripts to persist, i
don’t think the example script on the wiki returns the appropriate
return codes for a persistent thing like that.
Is this an old-school CGI script, or something intentionally built to be
a
FastCGI program? You’d need the latter… If you don’t want to move on
to
FCGI::Async, you could at least do this:
use CGI::Fast;
while (my $cgi = CGI::Fast->new()) {
# your old program here, using $cgi where
# you’d use CGI->new() from CGI.pm
}
Then your script will persist. You’ll still have to run it via some
other
FastCGI starting program, like the one that’s included with lighttpd, I
think
it was ‘spawn-fcgi’.
I prefer to build them from the ground up to be FastCGI programs myself,
but
this works in a pinch.
Well these can run non-persistent, that is fine. I just didn’t see a
way to get nginx to execute them without having to do some sort of
upstream passing?
I googled for nginx and CGI and that’s the page I got I’d prefer a
simpler solution…
I would prefer not to have FastCGI needed. So - is there a simple way
to get nginx to execute .cgi / .pl / etc perl scripts itself? or some
easy hack like that?
No, and Igor has made it clear there are no plans to add CGI support to
Nginx.
The preferred solutions would be (in order):
Don’t use CGI. It’s inefficient and outdated. If you can, rewrite
your scripts to use FastCGI.
Proxy to a simple http server such as thttpd to serve up CGI scripts.
Use the FastCGI wrapper provided on the wiki (perhaps provide a patch
if it’s inadequate in some way). Ultimately this is your “easy hack”.
Is this an old-school CGI script, or something intentionally built to be a
FastCGI program? You’d need the latter… If you don’t want to move on to
FCGI::Async, you could at least do this:
use CGI::Fast;
while (my $cgi = CGI::Fast->new()) {
your old program here, using $cgi where
you’d use CGI->new() from CGI.pm
}
if you’ve got a way to tack this on to bugzilla i’m all for it.
otherwise, i don’t want to touch bugzilla’s core code at all.
Then your script will persist. You’ll still have to run it via some other
FastCGI starting program, like the one that’s included with lighttpd, I think
it was ‘spawn-fcgi’.
i had issues with spawn-fcgi with PHP fastcgi engines… and i don’t
need these scripts to “persist” i just need something to execute cgi
scripts from nginx… there will be requests to tons of separate .cgi
files so that layer would have be its own layer then sending the
request to the .cgi files themselves (which i believe what the wiki
simplecgi example does)
if you’ve got a way to tack this on to bugzilla i’m all for it.
otherwise, i don’t want to touch bugzilla’s core code at all.
Ugh, that’s plain old CGI? Remind me to stay away.
Oh yeah, I use Trac, it supports FastCGI
But still, I bet with some poking around, it wouldn’t be too hard to
write a
wrapper to handle the FastCGI -> CGI translation, if you know a bit of
perl.
i had issues with spawn-fcgi with PHP fastcgi engines… and i don’t
need these scripts to “persist” i just need something to execute cgi
scripts from nginx… there will be requests to tons of separate .cgi
files so that layer would have be its own layer then sending the
request to the .cgi files themselves (which i believe what the wiki
simplecgi example does)
No, you need something that’s FastCGI to persist, and that to
execute your
other code (by some method). spawn-fcgi is for running FastCGI stuff,
not
CGI programs, so it’s useless here without some FastCGI to CGI wrapper
thing.
Which I think is what that Wiki page was getting at. (Note: I don’t use
spawn-fcgi either)
I’m with Igor here, let CGI die, and good riddance. Maybe submit a bug
to
Bugzilla asking for FastCGI support?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.