Mailing List Archive

Embperl logging "out of control"
Folks,

We run Embperl 1.3.6 under mod_perl 1.29 and Apache/1.3.31. Recently we'd
noticed that Embperl seems to be logging "everything." So much stuff that
we have to truncate them every hour or so.

Below is a snippet from one of our httpd.conf files, which contains the
embperl directives. It looks like this was intended to shut off Embperl
logging, but it's not working. I've tried to debug this, for instance by
using PerlSetEnv to set the variables, or setting EMBPERL_DEBUG to 1. The
only thing that's been effective so far is setting the EMBPERL_LOG to
/dev/null - not a very elegant elegant solution there.

7 PerlSetEnv EMBPERL_SESSION_HANDLER_CLASS no
8 SetEnv EMBPERL_SESSION_HANDLER_CLASS no
9 SetEnv EMBPERL_OPTIONS 1024
10 SetEnv EMBPERL_COMPARTMENT test
11 SetEnv EMBPERL_LOG /some/custom/directory.txt
12 SetEnv EMBPERL_DEBUG 0

Any help is appreciated.
--
Regards,
Tim Grant
Application Developer


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl logging "out of control" [ In reply to ]
We had an incident like that back in our development of our pages. We
tracked it down to someone having set EMBPERL_DEBUG to -1 in one of
their pages, and assumed that the automatic garbage collection at the
end of the page would fix it up. So whenever an apache child showed
that page, it'd start logging like this.

I found it by grepping the log file for EMBPERL_DEBUG, if I remember
correctly. Note that it didn't actually log the section that did it to
us on the *first* pass through that page for any child. But it did, of
course, tattle if a child showed the same page twice.

Of course, if the bug was in perl code, rather than one of our pages, we
wouldn't have caught it that way. Instead, we'd have caught it from my
earlier grep of all of our perl code and all of the non-EmbPerl library
code for EMBPERL_DEBUG.


Note that, while it wouldn't solve your issue, you could make a web page
to report those same variables, and when you found out which one was
wrong, modify some pages to fix it. Of course, this sort of kludge-fix
should only be used as a last resort.


I am assuming that all of your processing is within Apache. We've also
had an issue regarding excessive debugging output from offline
processing, that was initially blamed on our more prominent
Apache-directed processing.

Ed

On Wed, 12 Dec 2007 Tim_Grant@vwr.com wrote:

> Folks,
>
> We run Embperl 1.3.6 under mod_perl 1.29 and Apache/1.3.31. Recently we'd
> noticed that Embperl seems to be logging "everything." So much stuff that
> we have to truncate them every hour or so.
>
> Below is a snippet from one of our httpd.conf files, which contains the
> embperl directives. It looks like this was intended to shut off Embperl
> logging, but it's not working. I've tried to debug this, for instance by
> using PerlSetEnv to set the variables, or setting EMBPERL_DEBUG to 1. The
> only thing that's been effective so far is setting the EMBPERL_LOG to
> /dev/null - not a very elegant elegant solution there.
>
> 7 PerlSetEnv EMBPERL_SESSION_HANDLER_CLASS no
> 8 SetEnv EMBPERL_SESSION_HANDLER_CLASS no
> 9 SetEnv EMBPERL_OPTIONS 1024
> 10 SetEnv EMBPERL_COMPARTMENT test
> 11 SetEnv EMBPERL_LOG /some/custom/directory.txt
> 12 SetEnv EMBPERL_DEBUG 0
>
> Any help is appreciated.
> --
> Regards,
> Tim Grant
> Application Developer

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
RE: Embperl logging "out of control" [ In reply to ]
Thanks to everyone for the replies. I'll get to them all, but I can answer
Sherman Culler's questions now.

>Just curious - why not upgrade Apache/Embperl/mod_perl to the latest
>versions - Apache 2.x, Embperl 2.x and mod_perl 2?

We tried this a while ago. Embperl 2 is stricter with its HTML validation
and Perl syntax than version 1, and this caused a lot of headaches with our
legacy code. The project was killed.

>>Do you use virtualhost directives?

We do, but only for our some environments. We first noticed the problem on
machines that don't use them.

>>I need some more information about how your server is setup.

What do you need?

>>Have you read the documentation at
http://perl.apache.org/embperl/pod/doc/doc13/HTML/Embperl.-page-4-.htm ?

Yes.

>>Why do you use PerlSetEnv for the first line and then SetEnv for the
following lines?

I don't have an answer, as I didn't write that code. All of these are
global settings, not per directory, so it would seem SetEnv would be fine
for all. But my jimmying things around didn't fix anything, so I provided
the code I inherited.

--
Regards,
Tim Grant
Application Developer, VWR International
610-719-7097


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl logging "out of control" [ In reply to ]
>We had an incident like that back in our development of our pages. We
>tracked it down to someone having set EMBPERL_DEBUG to -1 in one of
>their pages, and assumed that the automatic garbage collection at the
>end of the page would fix it up. So whenever an apache child showed
>that page, it'd start logging like this.

Great tip. Doesn't seem to be what's happeninig here.

>I found it by grepping the log file for EMBPERL_DEBUG, if I remember
>correctly. Note that it didn't actually log the section that did it to
>us on the *first* pass through that page for any child. But it did, of
>course, tattle if a child showed the same page twice.

Grepping our logs for EMBPERL_DEBUG returned no results.

>Of course, if the bug was in perl code, rather than one of our pages, we
>wouldn't have caught it that way. Instead, we'd have caught it from my
>earlier grep of all of our perl code and all of the non-EmbPerl library
>code for EMBPERL_DEBUG.

Grepping our code for EMBPERL_DEBUG returned no results.

>Note that, while it wouldn't solve your issue, you could make a web page
>to report those same variables, and when you found out which one was
>wrong, modify some pages to fix it.

We have a report page. Here's an excerpt:

EMBPERL_COMPARTMENT test
EMBPERL_DEBUG 0
EMBPERL_LOG /www/logs/www.vwrsp.com.embperl.log
EMBPERL_OPTIONS 1024
EMBPERL_SESSION_HANDLER_CLASS no

...

REDIRECT_EMBPERL_COMPARTMENT test
REDIRECT_EMBPERL_DEBUG 0
REDIRECT_EMBPERL_LOG /www/logs/www.vwrsp.com.embperl.log
REDIRECT_EMBPERL_OPTIONS 1024
REDIRECT_EMBPERL_SESSION_HANDLER_CLASS no

When I look at that, it says to me that Embperl logging should be off. I've
reloaded the page a lot, and haven't seen the EMBPERL_DEBUG variable
change.

(BTW, I don't know what this redirect stuff is. I've seen very little
mention of it on the internet.)

>>I am assuming that all of your processing is within Apache.

Correct.

--
Regards,
Tim Grant
Application Developer, VWR International
610-719-7097


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl logging "out of control" [ In reply to ]
Assuming you haven't found a resolution to the issue yet...

Have you tried running running Apache with a single child (MaxClients
1) to try to help isolate the issue? I realize this is only a viable
setup on a test machine.

The code hack in me would probably try putting something along the lines
of the following on a page, and then seeing if it affected the logging
of that page:

[- $ENV{EMBPERL_DEBUG} = -1; $ENV{EMBPERL_OPTIONS} = 1024|131072; -]
[- $ENV{EMBPERL_DEBUG} = 0; $ENV{EMBPERL_OPTIONS} = 1024; -]

The purpose behind this twiddling is that in some environments (I don't
believe that EmbPerl is one of them, but I don't know for certain) there
are multiple variables which track the same settings; the public
interface has nothing to do with the actual functioning, other than
being used to detect changes to the settings. In these environments, if
the different variables somehow get out of sync, setting the public
interface varaible to the value it already has may not trigger a change
to be replicated to the internal state.

Ed

On Thu, 13 Dec 2007 Tim_Grant@vwr.com wrote:

>>We had an incident like that back in our development of our pages. We
>>tracked it down to someone having set EMBPERL_DEBUG to -1 in one of
>>their pages, and assumed that the automatic garbage collection at the
>>end of the page would fix it up. So whenever an apache child showed
>>that page, it'd start logging like this.
>
> Great tip. Doesn't seem to be what's happeninig here.
>
>>I found it by grepping the log file for EMBPERL_DEBUG, if I remember
>>correctly. Note that it didn't actually log the section that did it to
>>us on the *first* pass through that page for any child. But it did, of
>>course, tattle if a child showed the same page twice.
>
> Grepping our logs for EMBPERL_DEBUG returned no results.
>
>>Of course, if the bug was in perl code, rather than one of our pages, we
>>wouldn't have caught it that way. Instead, we'd have caught it from my
>>earlier grep of all of our perl code and all of the non-EmbPerl library
>>code for EMBPERL_DEBUG.
>
> Grepping our code for EMBPERL_DEBUG returned no results.
>
>>Note that, while it wouldn't solve your issue, you could make a web page
>>to report those same variables, and when you found out which one was
>>wrong, modify some pages to fix it.
>
> We have a report page. Here's an excerpt:
>
> EMBPERL_COMPARTMENT test
> EMBPERL_DEBUG 0
> EMBPERL_LOG /www/logs/www.vwrsp.com.embperl.log
> EMBPERL_OPTIONS 1024
> EMBPERL_SESSION_HANDLER_CLASS no
>
> ...
>
> REDIRECT_EMBPERL_COMPARTMENT test
> REDIRECT_EMBPERL_DEBUG 0
> REDIRECT_EMBPERL_LOG /www/logs/www.vwrsp.com.embperl.log
> REDIRECT_EMBPERL_OPTIONS 1024
> REDIRECT_EMBPERL_SESSION_HANDLER_CLASS no
>
> When I look at that, it says to me that Embperl logging should be off. I've
> reloaded the page a lot, and haven't seen the EMBPERL_DEBUG variable
> change.
>
> (BTW, I don't know what this redirect stuff is. I've seen very little
> mention of it on the internet.)
>
>>>I am assuming that all of your processing is within Apache.
>
> Correct.
>
> --
> Regards,
> Tim Grant
> Application Developer, VWR International
> 610-719-7097
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org