On Apr 8, 2007, at 11:00 AM, Bill Cole wrote:
At 7:25 PM +0200 4/8/07, Chaos Engine wrote:
Hi there, I got a daily cron (rdate to local time server) job wich adjusts
time and which constantly gives me headache.
Which is one reason (out of many) NTP was invented. :-)
Every day my dovecot suicides with:
"dovecot: Time just moved backwards by 11 seconds. This might
cause a lot of problems, so I'll just kill myself now."Of course my onboard clock is constantly off by more than 5 secs.
How "of course?"
The last time I had a machine's NTP synch stop working, it diverged
less than 2 seconds from reality in a week. Looking at a few
machines where the LOM cards have RTC's independent of the
motherboard RTC's, I see divergence of 0-4 seconds over the past 2
months.
MANY cheap PC RTCs drift like a log on the ocean in a hurricane. The
fact you mention a LOM card sort of indicates you might be looking at
a Sun or the like. Their clocks are better.
I don't want to abandon time synchronization and I want to use dovecot.
Frankly, using 'rdate' is not time synchronization. It's time
*setting* on a regular basis. It's like calling 'time' on the phone
every few minutes/hours and setting your watch to what it says. And
what you are rdating you clock to? Another machine that has a
drifting RTC? NTP has the concept of tiers, so you can trust the
Atomic Clock above the GPS Clock above the machine you think is
pretty good, which in turn is above you (broken, but better than
nothing) RTC.
Maybe a -HUP signal would do? What do you propose?
3 options
- Repair your hardware. Gaining 5 seconds per day is not normal,
and really should not be tolerated in a system that has to converse
with other machines.
Not always an option. :-)
- Set up something that will do the adjustment for you on a more
continuous basis. Xntpd will track your drift and keep you more in
sync on a continuous basis by slewing the clock rather than
stepping it back daily.
NTP is a LOT smarter than anyone realizes. It's best to use this,
because MANY *really smart* people have invested more time than is
reasonable in solving way more problems than you'll even encounter
running a machine.
- Make that cron job smarter but stopping Dovecot (and anything
else that might care about time moving backwards) ahead of the
change, and then waiting until your clock is back ahead of that to
restart them.There are technical strategies (e.g. Maildir naming) which rely on
the assumption of the clock never repeating the same second twice.
It's not just dovecot, by the way. MANY things don't like have time
move backward, like Cron, at, etc. You should *NEVER* have the clock
jump back in time (except during DST changes -- yuk).
The correct way to handle time on Unix systems is to set the clock at
boot (rdate, ntpdate, etc), and then *skew* the clock, so time slows
down to match the right time. It can always jump forward, but NTP
only jumps by a (settable) maximum amount per time-quantum. This
prevents things like make, and NFS caching, and a bunch of other
stuff "just work".
As far as I know, all shipping OSes now have a working NTP client,
and it's VERY easy to just add
server pool.ntp.org
to the ntpd.conf file, and you're good to go on reboot.
Sean