This seems a bit overkill:
http://wiki.codemongers.com/NginxSimpleCGI
Not to mention it’s not persistent. Anyone have any better tools to
keep Perl-capable fastcgi engines running?
I have it supposedly running at the moment (not ideal, but says it’s
running) …
Is there anything like php-fpm out there but for perl? 
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
On Tue, Jul 01, 2008 at 14:02:43, mike said…
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.
[fcgi-program:foo]
socket=unix:///tmp/%(program_name)s.sock //(or
tcp://:)
process_name = %(program_name)s_%(process_num)s
command = /bin/foo.fcgi
numprocs = 5
Roger
Maybe I should re-iterate 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?
On Tue, 2008-07-01 at 14:02 -0700, mike wrote:
This seems a bit overkill:
http://wiki.codemongers.com/NginxSimpleCGINot 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).
Cliff
On 7/1/08, Michael [email protected] wrote:
On Tue, Jul 01, 2008 at 14:02:43, mike said…
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.
On Tue, Jul 01, 2008 at 16:55:42, mike said…
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.
Okay -
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…
On Tue, 2008-07-01 at 16:56 -0700, mike wrote:
Maybe I should re-iterate 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?
No, and Igor has made it clear there are no plans to add CGI support to
Nginx.
The preferred solutions would be (in order):
Here’s some links that you might find useful:
http://www.acme.com/software/thttpd/
Cliff
On 7/1/08, Michael [email protected] wrote:
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)
On 7/1/08, Cliff W. [email protected] wrote:
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.
i -always- prefer PHP. even RoR or something else that has a better
solution for management.
- Proxy to a simple http server such as thttpd to serve up CGI scripts.
unfortunately, this is bugzilla. i can’t really -recode- bugzilla, and
unless someone knows how to run nginx+bugzilla…
it looks like i’m going with the thttpd solution. bleh. i hate
perl-based apps.
- 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”.
yeah… i don’t know perl well enough to want to try hacking
daemonized stuff and all that jazz. i have to support this in the
future…
On Tue, Jul 01, 2008 at 18:37:44, mike said…
it looks like i’m going with the thttpd solution. bleh. i hate perl-based
apps.
Perl has nothing to do with this, it’s the fact that you have a CGI
application
rather than a FastCGI application that’s the issue.
yeah… i don’t know perl well enough to want to try hacking
daemonized stuff and all that jazz. i have to support this in the
future…
In this case… I’m with the thttpd reccomendation, it’ll be easier.
On 7/1/08, Michael [email protected] wrote:
Perl has nothing to do with this, it’s the fact that you have a CGI application
rather than a FastCGI application that’s the issue.
if it was in php, i wouldn’t have this issue. etc 
yeah… i don’t know perl well enough to want to try hacking
daemonized stuff and all that jazz. i have to support this in the
future…In this case… I’m with the thttpd reccomendation, it’ll be easier.
yup, got it running and it works so far.
On Tue, Jul 01, 2008 at 18:39:56, mike said…
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.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs