Forum: NGINX FCGI.pm ?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
8072fdc83f765ae5075f252cb4d4d111?d=identicon&s=25 Chris Cortese (Guest)
on 2009-02-26 09:51
(Received via mailing list)
I'm trying to learn how to use the fastcgi-wrapper.pl from this link:
http://www.ruby-forum.com/topic/145858

1.  This requires FCGI.pm.  The only one I found on cpan.org throws a
great many errors when I try to run perl fast-cgi-wrapper.pl.  Where
should I get this from?  I'm running perl 5.8.8.

2.  I have one component on one site that does some AJAX to call a perl
backend.  Should this fastcgi-wrapper.pl work for me?  I can't really
find any docs that explain how to use it.  I'm not really a perl person
(mostly PHP).


Thanks,
Chris
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-02-26 10:18
(Received via mailing list)
look into fcgiwrap

http://nginx.localdomain.pl/wiki/FcgiWrap
http://www.ruby-forum.com/topic/148328

i haven't tried it yet but looked a lot easier/cleaner

On Thu, Feb 26, 2009 at 12:40 AM, Chris Cortese
8072fdc83f765ae5075f252cb4d4d111?d=identicon&s=25 Chris Cortese (Guest)
on 2009-02-26 10:49
(Received via mailing list)
Thanks.

I can't seem to build this though for Fedora 8.

I get fcgiwrap.c:4:24: error: fcgi_stdio.h: No such file or directory
cc1: warnings being treated as errors

I understand that I need libfcgi.  So I downloaded and installed:
rpm -i fcgi-2.4.0-6.fc8.x86_64.rpm

No change.

Any idea what I'm doing wrong?
09f5f6b58be8300f6edcd6b1641a3574?d=identicon&s=25 Anoop Alias (Guest)
on 2009-02-26 10:53
(Received via mailing list)
rpm -ql fcgi |grep fcgi_stdio.h

if it is not somewhere the c compiler expect it to be ..create a symlink



On Thu, Feb 26, 2009 at 4:35 PM, Chris Cortese
<cortese.consulting@gmail.com
8072fdc83f765ae5075f252cb4d4d111?d=identicon&s=25 Chris Cortese (Guest)
on 2009-02-26 11:19
(Received via mailing list)
I am still not finding this fcgi_stdio.h anywhere.

I went to these links:
http://rpmfind.net/linux/rpm2html/search.php?query...)
http://rpmfind.net/linux/RPM/fedora/updates/8/x86_...

I tried installing:

ftp://download.fedora.redhat.com/pub/fedora/linux/updates/8/SRPMS.newkey/fcgi-2.4.0-6.fc8.src.rpm
ftp://rpmfind.net/linux/fedora/releases/8/Everything/x86_64/os/Packages/fcgi-2.4.0-4.fc8.x86_64.rpm
ftp://rpmfind.net/linux/fedora/updates/8/x86_64.newkey/fcgi-2.4.0-6.fc8.x86_64.rpm

Any other place to find this stuff?


Thanks...
E88f834c0785a399b498b6cf70d10223?d=identicon&s=25 Grzegorz Nosek (gnosek)
on 2009-02-26 12:13
(Received via mailing list)
On czw, lut 26, 2009 at 02:09:20 -0800, Chris Cortese wrote:
> ftp://rpmfind.net/linux/fedora/updates/8/x86_64.newkey/fcgi-2.4.0-6.fc8.x86_64.rpm
>
> Any other place to find this stuff?

I don't use Fedora but try installing fcgi-devel (I guess that's the
right package name) as well as fcgi. You need the headers (fcgi-devel)
to compile fcgiwrap and the binaries (fcgi) to run it.

Best regards,
 Grzegorz Nosek
8072fdc83f765ae5075f252cb4d4d111?d=identicon&s=25 Chris Cortese (Guest)
on 2009-02-26 12:22
(Received via mailing list)
Thanks.  That got me a little closer.

Now, I have built fcgiwrap but I don't know how to use it.  From the
http://nginx.localdomain.pl/wiki/FcgiWrap page, can anyone elaborate on
what the following means?

You can then start fcgiwrap (possibly in several instances) using
spawn-fcgi or a similar tool (you must pass an open socket as fd 0; my
Spawner? will be very nice for this once I actually make it usable and
publish it) and send requests to it using fastcgi_pass. That's it.


Thanks.
2c6f80fff253635f12c249ef4f116796?d=identicon&s=25 Jim Ohlstein (Guest)
on 2009-02-26 12:45
(Received via mailing list)
The way I am using it (and the credit ALL goes to Grzegorsz who helped
me a great deal with it) on CentOS is to use the Perl script on that
page (http://nginx.localdomain.pl/wiki/FcgiWrap).

Then you add the following to the site config:

location ~ .pl$ {
fastcgi_pass unix:/tmp/cgi.sock;
include /usr/local/nginx/conf/fastcgi_params;
}

You can adjust the number of child processes to suit your needs.
E88f834c0785a399b498b6cf70d10223?d=identicon&s=25 Grzegorz Nosek (gnosek)
on 2009-02-26 13:13
(Received via mailing list)
On Thu, Feb 26, 2009 at 03:11:24AM -0800, Chris Cortese wrote:
> Thanks.  That got me a little closer.
>
> Now, I have built fcgiwrap but I don't know how to use it.  From the
> http://nginx.localdomain.pl/wiki/FcgiWrap page, can anyone elaborate on
> what the following means?
>
> You can then start fcgiwrap (possibly in several instances) using
> spawn-fcgi or a similar tool (you must pass an open socket as fd 0; my
> Spawner? will be very nice for this once I actually make it usable and
> publish it) and send requests to it using fastcgi_pass. That's it.

Yup. Providing the socket for fcgiwrap to listen on is your problem
(fcgiwrap doesn't care whether it is a tcp socket or a unix domain one
etc.). The simplest way to run a single fcgiwrap is to use spawn-fcgi,
like this:

spawn-fcgi -f /usr/local/bin/fcgiwrap -a 127.0.0.1 -p 8001

or

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

If you want to run multiple instances, give the Perl launcher from my
website a try.

Best regards,
 Grzegorz Nosek
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-02-26 18:58
(Received via mailing list)
On Thu, Feb 26, 2009 at 4:03 AM, Grzegorz Nosek
<grzegorz.nosek@gmail.com> wrote:

> Yup. Providing the socket for fcgiwrap to listen on is your problem
> (fcgiwrap doesn't care whether it is a tcp socket or a unix domain one
> etc.). The simplest way to run a single fcgiwrap is to use spawn-fcgi,
> like this:
>
> spawn-fcgi -f /usr/local/bin/fcgiwrap -a 127.0.0.1 -p 8001
>
> or
>
> spawn-fcgi -f /usr/local/bin/fcgiwrap -S /tmp/cgi.sock

Oh? spawn-fcgi will work too? Not the perl-based example? Cool. That
made life a little bit easier for me as I have scripts and things that
I had made to control spawn-fcgi stuff.

I'm still excited for a php-fpm style management daemon though :)

I will need to try spawn-fcgi + fcgiwrap soon!
2e321cc0efe9422d37165e922298494e?d=identicon&s=25 Cliff Wells (Guest)
on 2009-02-26 22:12
(Received via mailing list)
On Thu, 2009-02-26 at 01:35 -0800, Chris Cortese wrote:
> Thanks.
>
> I can't seem to build this though for Fedora 8.
>
> I get fcgiwrap.c:4:24: error: fcgi_stdio.h: No such file or directory
> cc1: warnings being treated as errors
>
> I understand that I need libfcgi.  So I downloaded and installed:
> rpm -i fcgi-2.4.0-6.fc8.x86_64.rpm

On Redhat systems you need the -devel RPM, probably fcgi-devel.

Cliff
8072fdc83f765ae5075f252cb4d4d111?d=identicon&s=25 Chris Cortese (Guest)
on 2009-02-27 11:43
(Received via mailing list)
What about the nginx equivalent for the Apache ScriptAlias directive for
cgi-bin?

I'm running fcgiwrap and have the following in my site config:

  location ~ .pl$ {
    fastcgi_pass unix:/tmp/cgi.sock;
    include /etc/nginx/fastcgi_params;
  }

My directory structure is like:  (higher up part of the path omitted for
simplicity)
/trunk/cgi-bin
/trunk/html/public/index.php

If I want to call http://mysite.com/cgi-bin/upload.pl    ...  How can I
tell nginx where to find this?


Thanks,
Chris
5447e06c6eeb471861633661aacc3659?d=identicon&s=25 luben (Guest)
on 2009-02-27 15:23
(Received via mailing list)
Some while ago I had problems starting perl fcgi processes and the
example code didn't worked for me. So I whote a little fcgi launcher,
optimized for perl applications.

You could find it attached to the message. It expects to have "run"
method for handling the request (CGI::Application integration) but you
could change the expected method name in the code to integrate with
different platforms. I could even make it an option if there is a need.

Use the code freely.
5447e06c6eeb471861633661aacc3659?d=identicon&s=25 luben (Guest)
on 2009-02-27 15:48
(Received via mailing list)
luben wrote:
> . It expects to have "run" method for handling the request
> (CGI::Application integration) but you could change the expected
> method name in the code to integrate with different platforms. I could
> even make it an option if there is a need.
>
After sending the message I found that I have already made the handler
method an option.
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-02-27 16:36
(Received via mailing list)
oh, dur. I would need one

spawn-fcgi fcgiwrap etc ...

for -every- "child" instance available. since it only does PHP
children itself, yeah?
2c6f80fff253635f12c249ef4f116796?d=identicon&s=25 Jim Ohlstein (Guest)
on 2009-02-27 17:22
(Received via mailing list)
Unless it has changed in the latest version (I haven't looked at the
documentation), spawn-fcgi's "-c" option only applies to php-cgi
processes. I tried it with fcgiwrap and got only one instance. Using the
script that Grzegorz wrote you can generate as many as you like, and
they are cheap memory-wise.

Sent from my Verizon Wireless BlackBerry
E88f834c0785a399b498b6cf70d10223?d=identicon&s=25 Grzegorz Nosek (gnosek)
on 2009-02-28 13:27
(Received via mailing list)
On czw, lut 26, 2009 at 02:20:18 -0800, mike wrote:
> oh, dur. I would need one
>
> spawn-fcgi fcgiwrap etc ...
>
> for -every- "child" instance available. since it only does PHP
> children itself, yeah?

It's your lucky day ;) Grab a new fcgiwrap snapshot and run it like:

spawn-fcgi (...) -- fcgiwrap -c 10

to have 10 processes preforked (the pool has a static size). This code
is rather experimental (may not survive a
kill-all-children-in-a-tight-loop
test) but looks like it's working.

Best regards,
 Grzegorz Nosek
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-02-28 23:13
(Received via mailing list)
fcgiwrap is slowly becoming a must have in my toolbox :)

hopefully soon i will start using it in production. want to get
comfortable with it first.

On Sat, Feb 28, 2009 at 4:17 AM, Grzegorz Nosek
2d7b00527275ec63e1fe115bd364e111?d=identicon&s=25 Roger Hoover (Guest)
on 2009-03-03 22:59
(Received via mailing list)
Supervisord can do all this and more.  It's a full service process
manager
that can manage daemons in any language, including pools of FastCGI
processes.

http://supervisord.org/

It has an XML-RPC interface and cmd line tool (supervisorctl) so you can
send commands to the process manager as it's running (for example,
starting
and stopping a given process or process pool).  It even has a
language-agnostic event listening API so that you can monitor process
manager events and take your own custom actions (such as sending
yourselves
alerts if a process dies).

Here's a sample config for managing a pool of 5 foo.pl processes and 2
bar.pl processes.

  [fcgi-program:foo]
        socket=tcp://127.0.0.1:4000
        process_name = %(program_name)s_%(process_num)s
        command = /path/to/foo.pl
        numprocs = 5

  [fcgi-program:bar]
        socket=unix:///path/to/fcgi/socket
        process_name = %(program_name)s_%(process_num)s
        command = /path/to/bar.pl
        numprocs = 2

The FCGI spawning has not been officially released but it's well unit
tested
in the SVN repo.  Just run easy_install
http://svn.supervisord.org/supervisor/trunk/
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-03-04 03:24
(Received via mailing list)
On Tue, Mar 3, 2009 at 1:45 PM, Roger Hoover <roger.hoover@gmail.com>
wrote:
> Supervisord can do all this and more.  It's a full service process manager
> that can manage daemons in any language, including pools of FastCGI
> processes.
>
> http://supervisord.org/

Isn't this somewhat like daemontools, or upstart? (Just with a few
more bells and whistles?)
2d7b00527275ec63e1fe115bd364e111?d=identicon&s=25 Roger Hoover (Guest)
on 2009-03-04 05:19
(Received via mailing list)
Without having used daemontools or upstart myself, I think those tools
are
intended to manage machine-level services and don't support pools of
identical processes nor FastCGI spawning.  Supervisord is more geared
toward
running application daemons which may have a different lifecycle.  If
you
have different groups of related processes in your application, you can
easily run each group under it's own instance of supervisord.  If you
run
FCGI processes in multiple languages, you don't need a separate process
manager for each language. If you run different kinds of deamons (like
FCGI,
STOMP, or AMQP), you don't need a separate process manager for each type
of
daemon.  Unlike spawn-fcgi (which is not really a process manager),
supervisord allows a pool of processes to share a single FCGI socket.

mod_fastcgi for Apache is both an FastCGI dispatcher and a process
manager.
When people switch to nginx, they often struggle with how to manage
their
processes and if they're not using php-fpm, they often turn to
spawn-fcgi,
which is very much lacking.  As it stands, supervisord can fill the gap
perfectly for mod_fastcgi's process manager for statically configured
processes.

For dynamically spawned processes, if someone were willing to write an
nginx
module to call supervisord's XML-RPC api, we'd have a complete,
language-agnostic replacement solution for mod_fastcgi.
E88f834c0785a399b498b6cf70d10223?d=identicon&s=25 Grzegorz Nosek (gnosek)
on 2009-03-04 09:50
(Received via mailing list)
On wto, mar 03, 2009 at 08:09:12 -0800, Roger Hoover wrote:
> For dynamically spawned processes, if someone were willing to write an nginx
> module to call supervisord's XML-RPC api, we'd have a complete,
> language-agnostic replacement solution for mod_fastcgi.

XMLRPC sounds evil ;) My checklist for required features looks like
below, how far is supervisord from meeting that?
 - killing idle processes after some timeout (with a configurable
   signal, preferably)
 - static pool size management (keep 5 of those running at all times)
 - dynamic pool size management (keep 1-5 running depending on load;
   this will require congestion notifications from the web server, like
   you said)
 - process status notifications ("foo failed to run, what now?", with
   some mildly intelligent retry logic) -- I need to alert an external
   entity somehow.
 - easily generated configuration file

If supervisord can do that, I'd be willing to write an Nginx module to
interface with that, sometime in this millenium.

Best regards,
 Grzegorz Nosek
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-03-04 10:04
(Received via mailing list)
Why not just make a php-fpm style thing like we talked about?

Define pools of fastcgi resources, with various configuration options,
timeout thresholds, error logging/capturing perhaps, ability to run as
different uid/gid per pool, adaptive process spawning (hard limits
etc.) ...

On Wed, Mar 4, 2009 at 12:40 AM, Grzegorz Nosek
E88f834c0785a399b498b6cf70d10223?d=identicon&s=25 Grzegorz Nosek (gnosek)
on 2009-03-04 10:54
(Received via mailing list)
On śro, mar 04, 2009 at 12:55:01 -0800, mike wrote:
> Why not just make a php-fpm style thing like we talked about?
>
> Define pools of fastcgi resources, with various configuration options,
> timeout thresholds, error logging/capturing perhaps, ability to run as
> different uid/gid per pool, adaptive process spawning (hard limits
> etc.) ...

[disclaimer: I haven't worked with supervisord yet, so I'm possibly
wrong about its capabilities]

Well, this is the foundation, which AIUI supervisord provides. However,
it has no possibility to know how busy the managed processes are and
when to spawn/kill (again, php-fpm has it too easy, it's not
implementable
this way in a generic process manager). Thus it needs some notification
from Nginx when it's overloaded (and when backends are idle -- but this
is a harder task).

So, to recap: supervisord alone allows you to run a statically-sized
pool of processes (with some nifty features like you mentioned above).

If you need dynamic pool sizing, you need some external help, either
from
Nginx, or possibly the kernel. What we're discussing here is not an
alternative to a dynamic process pool, it's one of the few sensible ways
to implement it in a language-agnostic way.

(BTW, I wonder whether supervisord can interface with PAM)

Best regards,
 Grzegorz Nosek
53d6845ee2656b1ef581523da50834b8?d=identicon&s=25 Jean-Philippe Moal (Guest)
on 2009-03-04 11:01
(Received via mailing list)
Grzegorz Nosek a écrit :
>  - dynamic pool size management (keep 1-5 running depending on load;
>    this will require congestion notifications from the web server, like
>    you said)
>  - process status notifications ("foo failed to run, what now?", with
>    some mildly intelligent retry logic) -- I need to alert an external
>    entity somehow.
>  - easily generated configuration file
>

I don't use it but God (http://god.rubyforge.org/) seems to respond to
your needs.
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-03-04 11:26
(Received via mailing list)
i am all for someone taking Grzegorz's work, and instead using the
perl launcher or spawn-fcgi, maybe add a bit more intelligence behind
it and make it simple for launching pools under different uid/gid with
different child counts, etc.

On Wed, Mar 4, 2009 at 1:50 AM, Jean-Philippe Moal
2d7b00527275ec63e1fe115bd364e111?d=identicon&s=25 Roger Hoover (Guest)
on 2009-03-04 18:14
(Received via mailing list)
On Wed, Mar 4, 2009 at 12:40 AM, Grzegorz Nosek
<grzegorz.nosek@gmail.com>wrote:

> On wto, mar 03, 2009 at 08:09:12 -0800, Roger Hoover wrote:
> > For dynamically spawned processes, if someone were willing to write an
> nginx
> > module to call supervisord's XML-RPC api, we'd have a complete,
> > language-agnostic replacement solution for mod_fastcgi.
>
> XMLRPC sounds evil ;) My checklist for required features looks like
> below, how far is supervisord from meeting that?


I'm not a huge XMLRPC fan either but Python makes it easy for the
project
implementers.  I suppose some other data format such as JSON is possible
if
there's a will.

>
>  - killing idle processes after some timeout (with a configurable
>   signal, preferably)


I think it's difficult to kill individual processes that have timed out
when
a pool of processes are all listening on the same FCGI socket because
nginx
would not know which process had accepted the request that timed out
(unless
there is some mechanism in the FCGI protocol to do this).  However, the
entire process pool could be killed/restarted if that's the behavior you
desire.


>
>  - static pool size management (keep 5 of those running at all times)


This is already available in supervisord


>
>  - dynamic pool size management (keep 1-5 running depending on load;
>   this will require congestion notifications from the web server, like
>   you said)


Functionality was recently added to supervisord to modify it's
configuration
dynamically through the XML-RPC api so this is matter of implementing
the
load logic in an nginx plugin and making calls to supervisord to add and
subtract from the pool.


>
>  - process status notifications ("foo failed to run, what now?", with
>   some mildly intelligent retry logic) -- I need to alert an external
>   entity somehow.


Depends on what kind of failure.  If process foo exits with an
unexpected
exit code, supervisord has an event listening API (a simple text
protocol
listening on a pipe) that allows you to write an event handler in any
language to deal with those events.  However, if process foo fails in
the
sense of returning a 500 status code or not returning any data at all,
that
would have to be handled by nginx module.


>
>  - easily generated configuration file


I think the config is pretty simple but I'll let you be the judge (
http://supervisord.org/manual/current/configuration.html).  I generate
supervisord configs dynamically in my current company using Perl
Template
Toolkit.
2d7b00527275ec63e1fe115bd364e111?d=identicon&s=25 Roger Hoover (Guest)
on 2009-03-04 18:34
(Received via mailing list)
Precisely.  With regard to PAM, I think the answer is no.
Authentication/Authorization for the XMLRPC API are done using
configured
username/password.  The risk is somewhat limited by the fact that it can
use
a unix domain socket so that at least exposure is limited to the
machine.
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-03-04 21:02
(Received via mailing list)
On Wed, Mar 4, 2009 at 9:03 AM, Roger Hoover <roger.hoover@gmail.com>
wrote:

>>  - dynamic pool size management (keep 1-5 running depending on load;
>>   this will require congestion notifications from the web server, like
>>   you said)
>
> Functionality was recently added to supervisord to modify it's configuration
> dynamically through the XML-RPC api so this is matter of implementing the
> load logic in an nginx plugin and making calls to supervisord to add and
> subtract from the pool.

While I would like to keep my software stack low, this sounds like a
neat benefit. Would just need to define hard upper limits, and how
long to wait or whatever to kill spare/unused children (like apache, I
suppose)

Personally I would like to see a daemon that does this in itself.
Leverages the fcgiwrap code + adds on features. I suppose it would
have to be 'aware' of how many connections it was servicing per pool
which Grzegorz makes it sound like can be very hard... but then it
could manage things dynamically.

request comes in -> depending on what port/socket/etc. it checks the
pool, determines if any children are open (if more needed, spawn like
apache, maybe log a notice in the log), changes to proper uid/gid if
configured, then executes the fastcgi stuff, if it gets back an error,
determine whether or not to log it, pass it back with the same http
code, do both, etc..

etc.

I don't understand enough about sockets, C, threading/forking/event
models/etc. to see if that is even an option but it seems like it
could be done, just not sure if it would be way too slow or not?
2d7b00527275ec63e1fe115bd364e111?d=identicon&s=25 Roger Hoover (Guest)
on 2009-03-04 21:46
(Received via mailing list)
On Wed, Mar 4, 2009 at 11:51 AM, mike <mike503@gmail.com> wrote:

> > load logic in an nginx plugin and making calls to supervisord to add and
> which Grzegorz makes it sound like can be very hard... but then it
> could manage things dynamically.
>
> request comes in -> depending on what port/socket/etc. it checks the
> pool, determines if any children are open (if more needed, spawn like
> apache, maybe log a notice in the log), changes to proper uid/gid if
> configured, then executes the fastcgi stuff, if it gets back an error,
> determine whether or not to log it, pass it back with the same http
> code, do both, etc..


>
> etc.


The approach you describe assumes that the parent process can intercept
socket connections as they come in.  I don't think this is possible
within
the constraints of the FastCGI spec.  Each FastCGI process is forked
with
file descriptor 0 pointing to a shared FastCGI socket and each child
process
just calls accept() on that socket.  The OS is responsible to
determining
which process in the pool accepts each request so there's no way for the
parent process to keep track of which child is taking which request.
Unless
that information can be retrieved from the kernel, I think the only
place
that load logic can be implemented is in an nginx module.
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-03-05 06:03
(Received via mailing list)
Hmm. Well

On Mar 4, 2009, at 12:34 PM, Roger Hoover <roger.hoover@gmail.com>
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-03-05 06:15
(Received via mailing list)
I am going to start a cgi-fpm project. The goals will be aligned like
php-fpm except slightly modified for the differences with cgi and
fastcgi. It might not be able to support adaptive spawning without
some sort of api or tools but at least will make management easier and
not require third party tools. It will basically enhance fcgiwrap with
php-fpm style configuration and hooks for external control for things
like an nginx module.

The annoyances with cgi and fastcgi can be discussed and hopefully
addressed.

Thoughts?

Also this could just be an nginx module too. But it would add some
weight and require suexec type stuff. So probably not a good idea.

Let me throw together a quick list of ideas.

On Mar 4, 2009, at 12:34 PM, Roger Hoover <roger.hoover@gmail.com>
2d7b00527275ec63e1fe115bd364e111?d=identicon&s=25 Roger Hoover (Guest)
on 2009-03-05 18:29
(Received via mailing list)
This is an interesting idea.  I'd like to see a generic process manager
come
out of the effort though, not just one that only works for wrapping CGI.
It
would be a great separation of concerns.   The CGI wrapper could focus
on a
single task: accepting FastCGI requests and forking CGI processes to
handle
them.  Process pool management could be handled by a generic FastCGI
process
manager, which could manage fcgiwrap pools and any other type of FastCGI
processes.
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-03-05 19:05
(Received via mailing list)
Sure - you mean anything that nginx (or any other server) speaks fastcgi
to

webserver <-> this process manager <-> code (perl cgi, or anything else)
?

Wouldn't this also be able to replace php-fpm then?

It seems like there are already ways using Tomcat/etc. for java,
php-fpm for PHP, ruby and python have managers, but CGI does not. Can
you give an example of what other things you'd want this to manage?
2d7b00527275ec63e1fe115bd364e111?d=identicon&s=25 Roger Hoover (Guest)
on 2009-03-05 21:32
(Received via mailing list)
On Thu, Mar 5, 2009 at 9:56 AM, mike <mike503@gmail.com> wrote:

> Sure - you mean anything that nginx (or any other server) speaks fastcgi to
>

Yes!


>
> webserver <-> this process manager <-> code (perl cgi, or anything else) ?
>
> Wouldn't this also be able to replace php-fpm then?
>

Ideally, yes.  Even with PHP's unique lifecycle (all objects discarded
after
each request), I don't see a reason why process pool management needs to
be
built in to PHP FastCGI handling.  Each PHP process could manage the
request
lifecycle for itself while the process pool management could be handled
generically, just like any other language.


>
> It seems like there are already ways using Tomcat/etc. for java,
> php-fpm for PHP, ruby and python have managers, but CGI does not. Can
> you give an example of what other things you'd want this to manage?


In short, I'd be happy if it exactly matched the process management
features
of mod_fastcgi for Apache.  mod_fastcgi does both FastCGI proxying and
process management.  Nginx + other event driven webservers implement the
FastCGI proxying piece but not the process management piece.

You're right that each language seems to have a different way of
managing
processes.  This is appealing when all the infrastructure you run is in
a
single language.  If you run ruby, you do it "the ruby way".  However,
the
organizations I've worked for need to run code in different languages,
for
various reasons including aquisition or migration.  I think everyone
would
benefit from a language agnostic process manage similar to mod_fastcgi
but
not tied to Apache.
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-03-06 01:26
(Received via mailing list)
I guess I would be more than happy then to stop using php-fpm and use
this new tool.

However I do like the benefits of php-fpm like the ability to override
some php.ini directives.

Perhaps we should get Grzegorz (fcgiwrap), Andrei (php-fpm) and others
together for this.

A generic fastcgi to (php|cgi|ruby|python|whatever) interface ?
2d7b00527275ec63e1fe115bd364e111?d=identicon&s=25 Roger Hoover (Guest)
on 2009-03-07 02:32
(Received via mailing list)
On Thu, Mar 5, 2009 at 4:15 PM, mike <mike503@gmail.com> wrote:

> I guess I would be more than happy then to stop using php-fpm and use
> this new tool.
>
> However I do like the benefits of php-fpm like the ability to override
> some php.ini directives.
>

This seems like something that still appropriate for PHP's FCGI wrapper,
even if that wrapper no longer needs to manage pools of processes.


>
> Perhaps we should get Grzegorz (fcgiwrap), Andrei (php-fpm) and others
> together for this.
>

I'd love to see if there's interest in this idea.


>
> A generic fastcgi to (php|cgi|ruby|python|whatever) interface ?


A language-agnostic FastCGI process manager?  One process manager to
rule
them all and in darkness bind them. :)
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 mike (Guest)
on 2009-03-07 03:23
(Received via mailing list)
On Fri, Mar 6, 2009 at 5:22 PM, Roger Hoover <roger.hoover@gmail.com>
wrote:
> This seems like something that still appropriate for PHP's FCGI wrapper,
> even if that wrapper no longer needs to manage pools of processes.

I want management of pools so I can separate by uid/gid, limits of
children, and if applicable adaptive spawning limits

I believe php-fpm uses libevent, there's gotta be a way to make a
middleware style daemon for this that leverages a large amount of
php-fpm style concepts and even daemonizing code..

>> Perhaps we should get Grzegorz (fcgiwrap), Andrei (php-fpm) and others
>> together for this.
>
> I'd love to see if there's interest in this idea.
This topic is locked and can not be replied to.