FAQ
This is a long-shot/stabbing-in-the-dark post -- and I'm guessing this
might not have anything to do with DateTime.

Anyone have any suggestions what might be happening here?


I have this code running in a Catalyst app running under mod_perl:

try {
     $c->stash->{timezone} = DateTime::TimeZone->new( name => $time_zone );
} catch {
     $c->log->error( "Timezone '$time_zone' is invalid for account $account:
$_" );
};


And I'm seeing this in the logs:

[ERROR] "Timezone 'America/Los_Angeles' is invalid for account 77368: *Invalid
version format (non-numeric data)* at
/usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm line
17.
BEGIN failed--compilation aborted at
/usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm line
17.
Compilation failed in require at (eval 7248) line 3.


Compiles fine:

$ perl -c
/usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm
/usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm
syntax OK



On the same machine with same Perl:

$ perl -le 'use DateTime; my $tz = DateTime::TimeZone->new( name =>
"America/Los_Angeles" ); print $tz->name'
America/Los_Angeles



The app seems to run fine for quite some time, then it starts logging the
error above -- and oddly, it seems to be mostly the same process ID that
generates the errors. There's 30 Apache processes.

That is, I include the PID in the logs so I can do this:

$ fgrep -r Angeles error_log-20140106 | perl -nle 'print $1 if /pid:(\d+)/'
sort | uniq -c
      21 31535
       6 32763


So, out of 30 Apache processes the errors are happing on only two PIDs and
mostly on one.

Here's line 17.

$ sed -n 17p
/usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm
use Class::Singleton 1.03;

$ perl -c /usr/share/perl5/Class/Singleton.pm
/usr/share/perl5/Class/Singleton.pm syntax OK




On an older CentOS machine:

This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi

$ perl -MDateTime::TimeZone::America::Los_Angeles -le 'print
DateTime::TimeZone::America::Los_Angeles->VERSION'
1.46

$ perl -MClass::Singleton -le 'print Class::Singleton->VERSION'
1.4

--
Bill Moseley
moseley@hank.org

Search Discussions

  • Bill Moseley at Jan 7, 2014 at 5:11 am
    Oh, and there's a different error message I'm seeing at the same place in
    the code:

    [ERROR] "Timezone 'America/Los_Angeles' is invalid for account 77368:
    Attempt to reload DateTime/TimeZone/America/Los_Angeles.pm aborted.
    Compilation failed in require at (eval 7258) line 3.




    On Mon, Jan 6, 2014 at 9:03 PM, Bill Moseley wrote:

    This is a long-shot/stabbing-in-the-dark post -- and I'm guessing this
    might not have anything to do with DateTime.

    Anyone have any suggestions what might be happening here?


    I have this code running in a Catalyst app running under mod_perl:

    try {
    $c->stash->{timezone} = DateTime::TimeZone->new( name => $time_zone );
    } catch {
    $c->log->error( "Timezone '$time_zone' is invalid for account
    $account: $_" );
    };


    And I'm seeing this in the logs:

    [ERROR] "Timezone 'America/Los_Angeles' is invalid for account 77368: *Invalid
    version format (non-numeric data)* at
    /usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm line
    17.
    BEGIN failed--compilation aborted at
    /usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm line
    17.
    Compilation failed in require at (eval 7248) line 3.


    Compiles fine:

    $ perl -c
    /usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm
    /usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm
    syntax OK



    On the same machine with same Perl:

    $ perl -le 'use DateTime; my $tz = DateTime::TimeZone->new( name =>
    "America/Los_Angeles" ); print $tz->name'
    America/Los_Angeles



    The app seems to run fine for quite some time, then it starts logging the
    error above -- and oddly, it seems to be mostly the same process ID that
    generates the errors. There's 30 Apache processes.

    That is, I include the PID in the logs so I can do this:

    $ fgrep -r Angeles error_log-20140106 | perl -nle 'print $1 if
    /pid:(\d+)/' | sort | uniq -c
    21 31535
    6 32763


    So, out of 30 Apache processes the errors are happing on only two PIDs and
    mostly on one.

    Here's line 17.

    $ sed -n 17p
    /usr/share/perl5/vendor_perl/DateTime/TimeZone/America/Los_Angeles.pm
    use Class::Singleton 1.03;

    $ perl -c /usr/share/perl5/Class/Singleton.pm
    /usr/share/perl5/Class/Singleton.pm syntax OK




    On an older CentOS machine:

    This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi

    $ perl -MDateTime::TimeZone::America::Los_Angeles -le 'print
    DateTime::TimeZone::America::Los_Angeles->VERSION'
    1.46

    $ perl -MClass::Singleton -le 'print Class::Singleton->VERSION'
    1.4

    --
    Bill Moseley
    moseley@hank.org


    --
    Bill Moseley
    moseley@hank.org
  • Dave Rolsky at Jan 7, 2014 at 9:53 pm

    On Mon, 6 Jan 2014, Bill Moseley wrote:

    I have this code running in a Catalyst app running under mod_perl:
    I'm inclined to blame mod_perl, since in my experience it tends to do
    weird things when loading modules, depending on how you load them
    (PerlRequire vs in module loaded via a handler, etc.).

    The bit in your other message about "attempt to reload ... aborted" makes
    me wonder if you are for some reason using Apache(2)::Reload or something
    similar in production. If you are, you really shouldn't.

    You may just want to punt and run the app via starman or something like
    that, too. I find this to be much simpler when using Catalyst. There's
    less magic.


    -dave

    /*============================================================
    http://VegGuide.org http://blog.urth.org
    Your guide to all that's veg House Absolute(ly Pointless)
    ============================================================*/
  • Bill Moseley at Jan 8, 2014 at 5:39 pm
    Thanks Dave for looking at this.
    On Tue, Jan 7, 2014 at 1:53 PM, Dave Rolsky wrote:

    On Mon, 6 Jan 2014, Bill Moseley wrote:

    I have this code running in a Catalyst app running under mod_perl:
    I'm inclined to blame mod_perl, since in my experience it tends to do
    weird things when loading modules, depending on how you load them
    (PerlRequire vs in module loaded via a handler, etc.).
    Yes, that was one of my guesses, too. But, I find it very odd that only
    one process does this. And often within the first or second request that
    child process handles.

    That message "Invalid version format (non-numeric data)" comes from
    version.pm (the XS part). It would be nice to know what that non-numeric
    data is, so we rebuilt a new version.pm package adding more debugging. And,
    as you might expect, the problem has not resurfaced with the debugging code
    in place.


    The bit in your other message about "attempt to reload ... aborted" makes
    me wonder if you are for some reason using Apache(2)::Reload or something
    similar in production. If you are, you really shouldn't.
    We are not using Apache2::Reload.

    I'm pretty sure that's just the same issue as "Invalid version format
    (non-numeric data)". Perl fails to compile TimeZone::America::LosAngeles
    and spits out that invalid version error. Then subsequent attempts to
    compile it in the same process generates the "attempt to reload" error.

    I still don't see how this is an issue with DateTime. Seems more like
    something bugging on the machine.

    You may just want to punt and run the app via starman or something like
    that, too. I find this to be much simpler when using Catalyst. There's less
    magic.
    Yes, I agree about Starman. Much cleaner. Unfortunately, the operations
    team isn't quite ready for the cutting edge -- we are on 5.10.1, after all.
    :).






    -dave

    /*============================================================
    http://VegGuide.org http://blog.urth.org
    Your guide to all that's veg House Absolute(ly Pointless)
    ============================================================*/


    --
    Bill Moseley
    moseley@hank.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdatetime @
categoriesperl
postedJan 7, '14 at 5:04a
activeJan 8, '14 at 5:39p
posts4
users2
websitemetacpan.org...

2 users in discussion

Bill Moseley: 3 posts Dave Rolsky: 1 post

People

Translate

site design / logo © 2019 Grokbase