Well, I think the solutions or ideas are maybe a bit too involved. I was hoping that the errors I am interested in were already logged by default to some obscure location, and I *could* if needed just go and scrutinize them by hand. But, it seems like a detailed (specially mysql) error log does not exist and thus cannot be scrutinized. Reading some of the possible solutions regarding adding error_log() functions to existing code leads me to believe that it could be easier to maybe incorporate those functions into PHP by means of a switch in php.ini, one could theoretically have two sets of functions, a mysql_query() for "normal" use that acts as we all know it, and another mysql_query() (yes, with the same name), that has the error_log() function call built into it, and the one that gets used is determined by the (lets call it) mysql_error_log = on in php.ini. This way, the entire thing will be transparent to both users and existing/future code. Granted, I have no idea how PHP is coded "behind the scenes" and if something like this is even possible, it's simply an idea, and hopefully some of the more learned people on this list will be able to comment on the feasability of something like that.
Dave wrote: >>><clipped> >>> >>>>>how about this curve... getting PHP to append a line to the apache log. >>>>> >>>>How about reading the documentation? >>>> >>>Deserved that for not being clear enough... see below. >>> >>My apologies if I missed the word "access log" or even assumed you meant >>"error log" when you just said "log." I shouldn't have. >> > >RTFM never hurt anyone :) > >>You're right, you can't do that, without opening up security more than you >>want to. >> >>*ACTUALLY*... >> >>There *probably* is an Apache function for access logs just like the error >>logging one that PHP is using, and you could *PROBABLY* patch PHP with some >>dead-easy copy&paste to use it, and you could even submit that worthy patch >>to the PHP Group. I suspect it's not there only because nobody really saw a >>need for it. >> > >I've never had a use for it untill now, wanting to charge a customer for massive >uploads via file_upload forms... transfer that is not recorded in the apache >logs and therefor not collected for billable bandwidth (while still preserving >IP addresses and avoiding a ipfw counting per IP). Probably a requirement with >limited scope. > >>It's kinda icky that you'd almost have to use 4 (the next unused number) for >>"Apache access log" with 0 being "Apache error log" and 1,2,3 being other >>stuff between... Maybe -1 for "access log"? Ewwwww. That's not 'right' >>either, but maybe it's 'less wrong' than 4. >> > >icky, I agree > >>Damn things shouldn't have been magic numbers in the first place. Should be >>constants. Hey, while you're in there, make up some decent constant names >>and let's migrate to them and then deprecate the magic numbers and fix it >>right :-) >> > >:) > >>Another option might involve some sort of nasty named pipe stuff and >>redirection and whatnot, and you *MIGHT* be able to have a "file" that you >>error_log into, but it really just ends up going into the Apache log... >>There may be some risk of corrupting your access log, however, if any >>incredibly *HUGE* entry over-steps the atomicity threshold for file >>appending in Linux... >> > >sounds like a nest of potential problems > >>Not so sure it's a Good Idea anyway to have two programs trying to write to >>the same file at once if it can be avoided. >> > >thus the interim solution of having PHP write to a seperate log file, then doing >a merge/sort during rotation time. > >Will look into it to see if something can be presented without creating more >problems than the solution is worth. > >Cheers, > >Dave > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
