mod_cgi for nginx - anyone?

mike mike503 at
Sat Feb 7 14:21:23 MSK 2009

On Feb 7, 2009, at 2:57 AM, Igor Sysoev <is at> wrote:

> On Sat, Feb 07, 2009 at 02:33:09AM -0800, mike wrote:
>> On Sat, Feb 7, 2009 at 2:16 AM, Igor Sysoev <is at> wrote:
>>> nginx is not general purpose server, it's rather highload server.
>>> CGI is not compatible with highload: if you run Apache/CGI, then CGI
>>> will became bottleneck much earlier than Apache.
>>> There are two ways to implement CGI inside nginx:
>>> 1) simple one: just fork()ing worker process that has received a  
>>> request
>>> for CGI and exec() a CGI program. It's simple enough, but has a lot
>>> of overhead. Besides CGI programs will run with worker privilege  
>>> only.
>> and it requires the CGI program to be modified, yeah?
> No.

Got any urls for examples then?

>>> 2) complex way: to run a special CGI manager (probably with root  
>>> privilege
>>> as master process) and to pass it requests/sockets using Unix  
>>> domain sockets.
>>> Then the manager can fork/exec CGI programs with required privileges
>>> and with minimal overhead to nginx workers.
>>> The second way will require some time to program, but the outcome  
>>> will
>>> be much similar like just proxying to mini_httpd
>>> ( ).
>> this is like starting out with something like php-fpm, and morphing
>> into a small httpd?
> No, the special CGI manager is a nginx process that fork()ed by  
> master nginx
> process (like worker processes). The communication protocol between
> workers and the manager is not HTTP: a worker starts to handle a  
> request,
> then it sees that the request should be handled by CGI, something like
>      location /mailman/ {
>           cgi_script  ...;
>           cgi_user    ...;
>           ...
>      }
> and pass the request and client socket to the manager.
>>> BTW, it seems that using Apache with several worker processes  
>>> (2-5) for
>>> bugzilla, mailman, etc. will not consume much CPU/memory: look top.
>> I'm just looking at it from simplifying the system administration.
>> I know it is not the most performant, those tools are not my  
>> preferred
>> ones, I just have to support hosting them right now...
> I understand this, but currently nginx has more priority tasks.

Sure. So it isn't impossible if someone else was hired to do it. I was  
wondering if there was a technical reason for it.

On a different note, I've paid someone to implement mod_auth_gss (more  
or less) into nginx. So it might support kerberos tickets and single  
sign on soon (at least SPNEGO)

> -- 
> Igor Sysoev

More information about the nginx mailing list