This turns out to be a bug in Hobbit on x86_64. Problem appears to be
that a time value read from the acknowledge.log by bbgen is read into a
shorter integer than is allocated as a time_t value (and that allocation
is not initialized)... so sometimes random bits are included, and skew
the time way into the future.
I solved the problem with the following patch:
--- lib/acklog.c.orig 2008-09-04 10:09:02.000000000 -0600
+++ lib/acklog.c 2008-09-04 10:11:59.000000000 -0600
@@ -72,7 +72,7 @@
}
}
- acks = (ack_t *) malloc(maxcount*sizeof(ack_t));
+ acks = (ack_t *) calloc(maxcount, sizeof(ack_t));
ackintime_count = num = 0;
while (fgets(l, sizeof(l), acklog)) {
@@ -87,7 +87,7 @@
char *p, *p1, *hobbitdacker = NULL;
sscanf(l, "%u\t%d\t%d\t%d\t%s\t%s\t%s\t%n",
- (unsigned int *)&acks[num].acktime,
&acks[num].acknum,
+ (time_t *)&acks[num].acktime,
&acks[num].acknum,
&acks[num].duration, &acks[num].acknum2,
ackedby, hosttest, color, &c_used);
Alan Sparks wrote:Trying to get a Hobbit 4.2.0+allinone server on CentOS 4.6 x86_64 running.
I am sometimes, when acknowledging an alert getting a very wrong date
string showing in the ack log at the bottom of the bb2 page. For instance:
Fri May 24 00:07:50 9630 den1log43 disk uiadmin (10.1.10.112)
asparks: blown datafile
Where in the world can "year 9630" be coming from?
The acknowledge.log has the following line:
1220503494 525808 60 525808 np_filename_not_used
den1log43.disk
yellow asparks: blown datafile, needs rebuild \nAcked by: uiadmin
(10.1.10.112)
Is this corrupt data somewhere? I've also tried removing the content of
acknowledge.log, but the problem returns as soon as I ack a new alert.
Thanks for any advice.
-Alan