FAQ
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

Search Discussions

  • Ed Grimm at Dec 12, 2007 at 7:11 pm
    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
  • Tim_grant at Dec 12, 2007 at 10:11 pm
    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
  • Tim_grant at Dec 13, 2007 at 6:15 pm

    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
  • Ed Grimm at Jan 8, 2008 at 12:28 am
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupembperl @
categoriesmodperl, perl
postedDec 12, '07 at 6:28p
activeJan 8, '08 at 12:28a
posts5
users2
websiteperl.apache.org

2 users in discussion

Tim_grant: 3 posts Ed Grimm: 2 posts

People

Translate

site design / logo © 2022 Grokbase