(This question also went to the regular mailing list, but I hadn't seen any feedback yet, and was feeling twitchy. :)
Hello, folks; hopefully someone could provide some advice on a certain matter. We've been mucking with an LDAP cluster that's managed via heartbeat. We have code that's supposed to manage expiring records when they're stale. We test our code by manually setting the system time (across all hosts) four months into the future. When we do this, we see heartbeat go into a tizzy, and lose the virtual interface (eth0:0). Oddly, the host still has this virtual IP associated with it, but heartbeat has lost track of it. Only a reboot seems to re-instantiate it. If I set the time back to the present, I see a useful message in the logs: info: Clock jumped backwards. Compensating. I tracked this diagnostic to LookForClockJumps(), and noticed that there was logic to detect a backwards skew of the system clock, but there was no logic to detect a pathological skew forward. Two questions: - Should setting the time for four months into the future have caused the symptoms we saw? This are _very_ reproducible. - Would a check for an unreasonable forward skew have prevent this symptom? This is on Red Hat 4 update 3, kernel version 2.6.9-34.ELsmp, and heartbeat 2.0.4. I noticed the LookForClockJumps() has not changed 2.0.7. (I also noticed no Red Hat RPMs for 2.0.7, but that's a separate observation. The supplied spec file is failing me. :) I can provide heartbeat logs, and tcpdump capture files, if anyone wants to poke. Anyway, I'd appreciate any advice/pointers you folks could provide... Thanks! -- Brian Reichert <[EMAIL PROTECTED]> 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
