* Originally in stats
* Crossposted in binkd

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

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

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

I see this is happening across all systems using that script. Do I
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 (<F>) {
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 (<F>) {
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. ---
* Origin: (1:3634/12.73)