I was able to access automc's crontab on
spamassassin2.zones.apache.org, so I set up two monitors: one that
checks to see if the ruleqa daemon is currently running (if it isn't
then see http://wiki.apache.org/spamassassin/InfraNotes for how to
restart it), and another that attempts to use ntpdate to check the
difference between the clocks on spamassassin2.zones.apache.org and
spamassassin.zones.apache.org and warn if the difference gets "too
great" (which is yet to be intelligently defined).
Both checks are currently run once daily, and will email a warning to
the dev list if they fail.
As the clocks are successfully synchronized at the moment, I don't
have any way to test whether the clock drift check will actually work.
Perhaps after we've gotten a rules update out we could ask someone in
Infra to temporarily change the clock on one or the other box and see
whether "ntpdate -q" will actually detect the problem.
Suggestions for a better way to check for clock drift are welcome.
Hi John,
Thanks for doing this. As for testing it, I'm hoping the time skew is a
unique situation that never repeats because I don't see a better way
than you devised.
Overall, though, theoretically Infra fixed ntpupdate on the master zone
for that box so even if they changed the time, my guess is there
ntpupdate would fix it very quickly. And unfortunately, purposefully
changing the time would change all the zones on that box.
So it's not something I would want to even ask to be tested on a
production box.
However, I don't know that your system for time skew check will work
without the zones1 running ntpd. Isn't it currently just return 0 skew
because it can't contact zones?
regards,
kAM
