I've got several GB of apache logfiles to process every month, currently using awstats 6.1. I had this "Month '18' out of range 0..11 at awstats.pl line 1044 the second time now; the last time has been a few months ago, now it happened with the december logs again. I suspect there's probably some illegal timestamp entries in my logfiles, though I'll be damned if I know how or where, especially as the month of the timestamp in the logs is the three letter abbreviation, not the number of the month;
unfortunately awstats just dies with this message and doesn't produce any history-data - it leaves two files with the extensions .bis and .xxxx in the history_data folder (xxxx being for numbers) and I don't know how to produce any stats-output with these files.
As a quick workaround in order to produce some stats, I've wrapped the offending lines of code in an eval-statement like so:
sub GetSessionRange {
my $starttime = my $endtime;
eval{
if (shift =~ /(\d\d\d\d)(\d\d)(\d\d)(\d\d)(\d\d)(\d\d)/) { $starttime = Time::Local::timelocal($6,$5,$4,$3,$2-1,$1); }
if (shift =~ /(\d\d\d\d)(\d\d)(\d\d)(\d\d)(\d\d)(\d\d)/) { $endtime = Time::Local::timelocal($6,$5,$4,$3,$2-1,$1); }
};
return $SessionsRange[1] if $@;
my $delay=$endtime-$starttime;
if ($Debug) { debug("GetSessionRange $endtime - $starttime = $delay",4); }
if ($delay <= 30) { return $SessionsRange[0]; }
if ($delay > 30 && $delay <= 120) { return $SessionsRange[1]; }
if ($delay > 120 && $delay <= 300) { return $SessionsRange[2]; }
if ($delay > 300 && $delay <= 900) { return $SessionsRange[3]; }
if ($delay > 900 && $delay <= 1800) { return $SessionsRange[4]; }
if ($delay > 1800 && $delay <= 3600) { return $SessionsRange[5]; }
if ($delay > 3600) { return $SessionsRange[6]; }
return "error";
}
This should simply replace any corrupted session record with a 30-120s-duration session, which would be a tolerable compromise for my needs. Do you have any other suggestions on what might be done in order to resolve the issue in a more elegant way? Are there any major drawbacks to this patch?
Kind regards
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
I've got several GB of apache logfiles to process every month, currently using awstats 6.1. I had this "Month '18' out of range 0..11 at awstats.pl line 1044 the second time now; the last time has been a few months ago, now it happened with the december logs again. I suspect there's probably some illegal timestamp entries in my logfiles, though I'll be damned if I know how or where, especially as the month of the timestamp in the logs is the three letter abbreviation, not the number of the month;
unfortunately awstats just dies with this message and doesn't produce any history-data - it leaves two files with the extensions .bis and .xxxx in the history_data folder (xxxx being for numbers) and I don't know how to produce any stats-output with these files.
As a quick workaround in order to produce some stats, I've wrapped the offending lines of code in an eval-statement like so:
sub GetSessionRange {
my $starttime = my $endtime;
eval{
if (shift =~ /(\d\d\d\d)(\d\d)(\d\d)(\d\d)(\d\d)(\d\d)/) { $starttime = Time::Local::timelocal($6,$5,$4,$3,$2-1,$1); }
if (shift =~ /(\d\d\d\d)(\d\d)(\d\d)(\d\d)(\d\d)(\d\d)/) { $endtime = Time::Local::timelocal($6,$5,$4,$3,$2-1,$1); }
};
return $SessionsRange[1] if $@;
my $delay=$endtime-$starttime;
if ($Debug) { debug("GetSessionRange $endtime - $starttime = $delay",4); }
if ($delay <= 30) { return $SessionsRange[0]; }
if ($delay > 30 && $delay <= 120) { return $SessionsRange[1]; }
if ($delay > 120 && $delay <= 300) { return $SessionsRange[2]; }
if ($delay > 300 && $delay <= 900) { return $SessionsRange[3]; }
if ($delay > 900 && $delay <= 1800) { return $SessionsRange[4]; }
if ($delay > 1800 && $delay <= 3600) { return $SessionsRange[5]; }
if ($delay > 3600) { return $SessionsRange[6]; }
return "error";
}
This should simply replace any corrupted session record with a 30-120s-duration session, which would be a tolerable compromise for my needs. Do you have any other suggestions on what might be done in order to resolve the issue in a more elegant way? Are there any major drawbacks to this patch?
Kind regards
Markus