Eric S. Johansson wrote: >>> /usr/local/camram/cgi-bin/logout.cgi: could not execute the script > ... >>> which should show up in th error log. fix perms problem, one set of >>> 500's went away. now working on second set. >> >> We could to this, but we would need to stat() or access() the CGI >> for almost nothing. > > well, I'm not asking for you to check permissions. My sgid wrapper > does that quite nicely as you can see above. ;-) > > what I'm asking for is for some mechanism of recording these errors > so I can find when I've done something wrong or something has gone > wrong.
Well, you know.. as everything else in the project, it is open to discussion for enhancements :-) In this case, I do agree, it would make pretty much sense to log an error message if the CGI has the wrong permissions, but the problem is that we can't know it in advance unless to add a new system call to check it. >>> another error that needs logging is: >>> >>> 192.168.0.30 - - [15/Mar/2006:15:17:08 --500] "GET /favicon.ico >>> HTTP/1.1" 404 0 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; >>> rv:1.8) Gecko/20051111 Firefox/1.5" >>> 1 >>> >>> I have a favicon.ico 0 len file in doc root but is it not seen. the log >>> entry should help with debugging the problem. >> >> Could you please log a bug for this? If this is not a >> misconfiguration problem, we should forget about it. > > I'll doublecheck the configuration today but I'm pretty sure it's > not miss configuration. But this highlight something that's really > important. It's okay to have a fast web server when everything is > set up correctly but there should be some way to tell the server > it's okay to run slowly but tell me enough information so I can > figure out what's wrong. It's okay if I have to recompile the server > or there's a special module that needs to get loaded out but a > system telling you what's going on on in the inside is invaluable. > This is one of my primary frustrations with Apache. It's big, it's > fat, and it won't tell you what the hell is going on. Yep, you are right. Well, by the moment we have the undocumented CHEROKEE_TRACE feature. However, it would be nice if we add a better "information collector" because the tracing mechanism is meant to be a debugging tool rather than a user utility. It seems to be another new task for the upcoming unstable branch :-) Ideas about it? >>> and last, just wondering, do you send stderror to the error log on >>> cgi calls? >> >> No, it doesn't. Do you think we should do it? >> >> I don't think it is a good idea. For example, for my case, I would >> get huge log files filled with a nasty warning message that the PHP >> prints when it is launched.. > > oh is very much a good idea. I have CGI programs that fail and the > error goes to standard error. Right now, all I know is I get a 500 > error and no clue about what's failing unless I am running the web > server on the commandline and then I see the output. this is great > unless I'm running on a machine with a bunch of "production" processes. > > I will admit however that in such a circumstance I probably should have > a totally different instance of Cherokee for my testing. But when > you're just making a little change that shouldn't affect anything, it > would be nice to have the error log telling you were very much mistaken So, if that behavior is configurable everybody would be happy. > as for the log files filling up, well that's what they are there > for. log rotate is one way to deal with the problem. And you have > just given me another good reason not to use PHP. ;-) I used to like PHP (for what it is meant to be used, and no more!) until I started working on the FastCGI handler. Dude, you can't even imagine how much time I have wasted because of its brain death FastCGI implementation! :-// -- Greetings, alo. _______________________________________________ Cherokee mailing list [email protected] http://www.0x50.org/cgi-bin/mailman/listinfo/cherokee
