|Main Archive Page > Month Archives > spamassassin-dev archives|
> 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.
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
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?