> Jeff Trawick <[EMAIL PROTECTED]> writes:
>
> > procattr->parent_{in,out,err} are the three file descriptors not
> > getting closed...
>
> These are created by apr_procattr_child_{in,out,err}_set().
>
> apr_procattr_child_*_set() is creating a pipe between parent and
> child, which isn't appropriate for mod_cgid since we want the new
> child to talk to another process (the apache child which sent the
> request to cgid).
>
> It is easy enough to close the cgid parent side of the pipe but what
> is needed is a way to set the child's stdin/stdout/stderr to the
> AF_UNIX socket without creating a pipe as a side effect.
>
Yep, the parent side pipes never being closed. Easy enough to close them thusly:
apr_close(newproc->in);
apr_close(newproc->out);
apr_close(newproc->err);
This is not the best solution though. Could probably make it more efficient by ditching
the APR calls and doing something like this...
cgid_process
while(1)
sd2 = accept()
apr_create_pool()
read(sd2,*) to setup env, blah, blah, blah from main server
pid = fork()
if (pid == 0) {
/* in the child */
dup2(sd2, STDIN);
dup2(sd2, STDOUT)
dup2(sd2, STDERR);
close(sd2);
exec()
exit -1
} else {
/* parent */
close(sd2);
}
apr_destroy_pool() /* this is also missing in cgid */
}
the cgid server needs to be a slim and clean as possible. If it leaks resources under
stress (or when the machine hits transient resource limits) then the cgid process will
eventually croak taking down CGIs entirely. There are three main problems with cgid
server now: leakes the parent side pipe handles, doesnt clean up the pool, and doesn;t
have logic to cleanup properly if any of the steps leading up to the apr_create_proc
call
fails.
Bill
