[Dovecot] Time just moved backwards

[Sean Kamath]

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
>
> 1. 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. :-)

> 2. 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.

> 3. 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