Re: Tracing script with problem
[snip] > > > > Another question, do you (or anyone else for that matter) know how the > > accesslog works? (and also why it does work like it does) It seems it > > prints after the request is done, otherwise could that easily be used > > for checking the parameters, and not only loging. > > You probably need to read some docs, which explain how can specify your > own access log format or supply your own log handler. > > For using the standard Apache formats see the docs at apache.org (you > also have them installed together with Apache under 'manual' dir on your > machine. For mod_perl examples you should probably see the eagle book, > check www.modperl.com (which seems to be offline now) if it has the > relevant chapters online, I think it's chapters 7 and 9 that you want. > > The guide has some info here: > http://thingy.kcilink.com/cgi-bin/modperlguide.cgi?q=PerlLogHandler our chapter on logging and the PerlLogHandler also happens to be online :) http://www.modperlcookbook.org/chapters/ch16.pdf --Geoff
Re: Tracing script with problem
Jon Molin wrote: > Stas Bekman wrote: > >>It's actually easy, take a look at the Apache::SizeLimit or >>Apache::GTopLimit, look at the cleanup handler that they register. Now >>take this handler and dump whatever you need to the file or error_log >>when you find that the process was taking too much memory. >> >>Take a look at this code and you will see that it's very simple. >> >> > > Thanks a bunch, I'll look into that. > > Another question, do you (or anyone else for that matter) know how the > accesslog works? (and also why it does work like it does) It seems it > prints after the request is done, otherwise could that easily be used > for checking the parameters, and not only loging. You probably need to read some docs, which explain how can specify your own access log format or supply your own log handler. For using the standard Apache formats see the docs at apache.org (you also have them installed together with Apache under 'manual' dir on your machine. For mod_perl examples you should probably see the eagle book, check www.modperl.com (which seems to be offline now) if it has the relevant chapters online, I think it's chapters 7 and 9 that you want. The guide has some info here: http://thingy.kcilink.com/cgi-bin/modperlguide.cgi?q=PerlLogHandler _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Tracing script with problem
Stas Bekman wrote: > > It's actually easy, take a look at the Apache::SizeLimit or > Apache::GTopLimit, look at the cleanup handler that they register. Now > take this handler and dump whatever you need to the file or error_log > when you find that the process was taking too much memory. > > Take a look at this code and you will see that it's very simple. > Thanks a bunch, I'll look into that. Another question, do you (or anyone else for that matter) know how the accesslog works? (and also why it does work like it does) It seems it prints after the request is done, otherwise could that easily be used for checking the parameters, and not only loging. /Jon > _ > Stas Bekman JAm_pH -- Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide http://perl.apache.org/guide > mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com > http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Tracing script with problem
Jon Molin wrote: > Hi list, > > I had problems with a script that went nuts and took 65MB memory and > alot of cpu. To track this script down I thought Apache:VMonitor would > be perfect, unfortenately I ran into some weird promlems (it said there > was an error in mod_perl.h) and i know gcc might be broken on this > machine so I started scratching my head and came to the conclusion that > this 'oneliner' ought to help me track the error down: > > find /www/docs -name '*.cgi' -type f -exec perl -pi -e > 's:(#!/usr/bin/perl[ w-]*\s*):$1\nprint STDERR "\\nPID=\$\$ > SCRIPT=\$ENV{REQUEST_URI} \\n";\n:s;' {} \; > > ie, every script now prints it's httpd pid and it's request_uri. So i > just started waiting watching top with excitment and when the 65 MB > httpd process i greped for the pid in the error_log and got the > scriptname and it's arguments. > > Then i reproduced the error on a server with VMonitor to see if what i > missed out. Ok i could see the name of the scrpit but the real problem > was with the query_string, choped after a couple of chars. Now, if i > understand things right (i tried some tweaking on the module) it's not > possible to get more than 64 char. Why is this, and is it really so? it's the limitation from apache scoreboard, it gives us only 64 chars. I don't think this is going to change this scoreboard must be very light and not to add an overhead to requests. > I know I'm no Einstein and i presume thousands of ppl have tried tracing > similar problems, how did you do it? There must be a more effective way > to find it? I know I would've got the script name but since i never > thought it would get the input it got chances are it'd take me a long > time finding the problem if i only knew the name. It's actually easy, take a look at the Apache::SizeLimit or Apache::GTopLimit, look at the cleanup handler that they register. Now take this handler and dump whatever you need to the file or error_log when you find that the process was taking too much memory. Take a look at this code and you will see that it's very simple. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Tracing script with problem
Hi list, I had problems with a script that went nuts and took 65MB memory and alot of cpu. To track this script down I thought Apache:VMonitor would be perfect, unfortenately I ran into some weird promlems (it said there was an error in mod_perl.h) and i know gcc might be broken on this machine so I started scratching my head and came to the conclusion that this 'oneliner' ought to help me track the error down: find /www/docs -name '*.cgi' -type f -exec perl -pi -e 's:(#!/usr/bin/perl[ w-]*\s*):$1\nprint STDERR "\\nPID=\$\$ SCRIPT=\$ENV{REQUEST_URI} \\n";\n:s;' {} \; ie, every script now prints it's httpd pid and it's request_uri. So i just started waiting watching top with excitment and when the 65 MB httpd process i greped for the pid in the error_log and got the scriptname and it's arguments. Then i reproduced the error on a server with VMonitor to see if what i missed out. Ok i could see the name of the scrpit but the real problem was with the query_string, choped after a couple of chars. Now, if i understand things right (i tried some tweaking on the module) it's not possible to get more than 64 char. Why is this, and is it really so? I know I'm no Einstein and i presume thousands of ppl have tried tracing similar problems, how did you do it? There must be a more effective way to find it? I know I would've got the script name but since i never thought it would get the input it got chances are it'd take me a long time finding the problem if i only knew the name. /Jon