* Originally in stats
* Crossposted in binkd

02 Jan 16 16:13, you wrote to me:

 ml>> damn a binkd log without the year in it!! screws up the stats on the
 ml>> roll over to the new year every damned time! }:|

 ml>> we won't even mention the problems with multi-year logs...

 PH> I see this is happening across all systems using that script. Do I
 PH> need to ammend the script or will it self resolve?

it has to do with the year crossing... in the section that reads the logs and
makes a unix time stamp with the data from the log, there is no year so the
year is forced to localtime[5] which is the current year... so when the script
runs, it is comparing the log lines with the wrong year to the date range
ending on Dec 31 of last year... of course if the log lines have a year forced
to this year and we're comparing with with last year, nothing will match so no
data is collected...

yes, it will self-correct but it will happen every year on the 1st of january
when attempting to process the last day of december of the previous year...

i spent some time messing with it yesterday and i think i have a fix... find
the "sub parse_log" routine... then find this section within it...


  while () {
    study $_;
    my ($day, $mon, $h, $m, $s, $pid, $cmd) =
/^..(..).(...).(..):(..):(..).\[(\d+)\].(.*)/ or next;
    my $dt = mktime($s, $m, $h, $day, $MON{$mon}, $YEAR, 0, 0, -1);


and change it to this...


  while () {
    study $_;
    my ($day, $mon, $h, $m, $s, $pid, $cmd) =
/^..(..).(...).(..):(..):(..).\[(\d+)\].(.*)/ or next;
    if ($MON{$mon} > (localtime)[4] && !defined $yearset) {
      $YEAR -= 1;
      $yearset = foo;
    }
    my $dt = mktime($s, $m, $h, $day, $MON{$mon}, $YEAR, 0, 0, -1);


what this does is to subtract 1 from the value in $YEAR if the month in the log
line we're processing is greater than the current month... that allows the
mktime line to generate the proper unix time stamp for the comparison...
%yearset is to keep $YEAR from being decremented for each log line processed...


we still can't process log files with more than last year and some of this year
in them, though... that would be quite easy if binkd also wrote the year to the
log file... i looked at the binkd code as well and i think i found the place in
tools.c where it can be changed but i'm not sure where to place the year... i'm
thinking maybe just before the PID because then the regexes in the scripts can
detect whether the year is there or not and use it if it is... i think...
something like this...

   my ($day, $mon, $h, $m, $s, $y, $pid, $cmd) =
/^..(..).(...).(..):(..):(..).(....)?.\[(\d+)\].(.*)/ or next;

i think that will work to detect a four digit year right before the [xxxxx] PID
portion of the log line... however i already see a problem with the extra space
which will need to be eaten some how... either the one before the (....) holder
for the year or the one after it and only when the year does not exist on the
line... that's gonna take some thinging and playing to figure out if i attempt
it at all ;)

by using four digit year we'll subtract 1900 from it to feed to the mktime line
using $y instead of $YEAR after $y is verified to contain valid year data...
otherwise, if the year is not in the log line, we'll use the existing method
with the modification i made above... of course, this is also a transitional
thing because once the logs all have the year in each log line, we won't have
to worry about it not being there unless we try to process old logs but then
that's going to have problems if they are older than the the current "last
year"...

)\/(ark

"So let me ask you a question about this brave new world of yours. When you've
killed all the bad guys, and when it's all perfect, and just and fair, and when
you have finally got it exactly the way you want it, what are you going to do
with the people like you? The trouble makers. How are you going to protect your
glorious revolution from the next one?" - The twelfth Doctor

... Reserve the apostrophe for it's proper use; omit it when its not needed.
---