Yes - this is with suexec
so the exec of suexec fails... that shouldn't make any difference (infamous last words) whether we run suexec or printenv/perl or whatever...
I'm guessing that in your scenario where the failure of exec() is due to heavy load, the file descriptors marked as close-on-exec have been closed prior to the point where the failure occurred, whereas in my scenario where I forced a hard exec() failure the kernel hadn't closed the file descriptors yet.
(The same issue arises in some other modules if this is really the case (exec failed *after* closing close-on-exec file descriptors) :( )
As for SIGPIPE, handling of it should only get set back to SIG_IGN when the new program is exec-ed (forked child about to run the CGI script (or suexec in your case) keeps the SIGPIPE settings of the cgid daemon process).
Maybe there is a Solaris patch for this :) It seems really sucky for exec to have a failure point after close-for-exec files are closed and after signal handling is reset.
If we really want that log file descriptor closed when the CGI script runs, then the child errfn can't use it and must write to stderr, since I believe that that is the only reporting mechanism guaranteed to be available regardless of where the failure to fork+tweak+exec occurred.
