Alvaro Lopez Ortega 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.
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.
Actually, it is odd.. does it only happen to you with empty files?
don't know. I'll create/steal a little picture and see if it changes
things.
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
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. ;-)
--- eric
_______________________________________________
Cherokee mailing list
[email protected]
http://www.0x50.org/cgi-bin/mailman/listinfo/cherokee
