> From: "Cliff Woolley" <[EMAIL PROTECTED]> > Sent: Wednesday, February 06, 2002 2:13 PM > > > > On 6 Feb 2002 [EMAIL PROTECTED] wrote: > > > > > +FINAL RELEASE SHOWSTOPPERS: > > > + > > > + * [Ken] Test suite failures: > > > + o worker is also failing some of the 'cgi' subtests > > > + (see <URL:http://Source-Zone.Org/Apache/regression/>): > > > + Justin says: "Worker should be fine and passes httpd-test > here. > > > + If you can provide evidence that it can be > reproduced > > > + outside of httpd-test, then it's a > showstopper. I > > > + think it's a perl or a httpd-test problem." > > > + Not a showstopper: Justin > > > + > > > > Sorry I never noticed this in the STATUS file before, but this is > exactly > > the same thing I was seeing on my machine for a while. Turns out if you > > run the tests as root and don't give the apache user rights to the logs > > directory, apache can't create the cgi-log, which causes all those tests > > to fail because they expect that log to be there. Change the directory > > permissions to allow the apache user to write to that directory > (normally > > a verrrrry bad thing, I know, but this is just for testing) and it will > > work. Alternatively, we could change the test to put the scriptlog > > someplace else... > > I suspect that forking the cgid process before we setuid, and letting the > cgid > engine setuid itself after it initializes should solve this bug. > > Either that, or the cgi-log needs to be opened in the main server config > so > the cgid deamon doesn't need to do so.
The cgi-log is always opened and written by the Apache child that is serving the request. It is closed at the end of the request. It is not meant to be used on a production server, it is strictly a debugging tool. Ryan
