mod_cgi for nginx - anyone?

Igor Sysoev is at
Sun Feb 8 13:11:19 MSK 2009

On Sat, Feb 07, 2009 at 09:38:41PM +0100, Manlio Perillo wrote:

> Igor Sysoev ha scritto:
> >[...]
> >
> >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.
> >
> This is not a problem from the Nginx point of view.
> Nginx should however put a limit on the number of concurrent CGI requests.
> It can use a queue to store outgoing request, and if the queue grows too 
> much return a 503 Service Unavailable, setting Retry-After to a 
> reasonable (computed?) value.
> No browser support 503 response, however.

I mean that using CGI as main response handler on highload site is useless.
CGI may be used for lowload tasks: monitoring, administration, etc. those
can be easly handled by Apache or by proxying to 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.
> >
> Nginx could use seteuid, instead of setuid.
> So that it can reacquire root privileges.

Yes, but it's not so safe as setuid().

> As for CGI support, some time ago I was trying to implement it.
> The idea was to use unix domain sockets (socketpair), and reusing the 
> http_upstream module.
> However I gave up, a lot of code for connection/upstream setup must be 
> rewritten, and I hate to write boiler plate code; and expecially having 
> to maintain it :).

Yes, CGI module should use modified upstream module.

> In Nginx one can also easily close all current opened file descriptors, 
> in child process; Nginx keeps all opened connection in the 
> ngx_cycle->free_connections variable so one can write a closefrom function.

This can be resolved using fcntl(F_SETFD, FD_CLOEXEC) too.

Igor Sysoev

More information about the nginx mailing list