[Dovecot] "Time just moved backwards" in Dovecot in a Xen DomU

Rob Middleton robm-dovecot at centenary.org.au
Tue Oct 6 16:25:23 EEST 2009


On 6/10/2009 12:54 PM, PGNet Dev wrote:
> <snip - from dom0>
> looking at my ntp logs around the same time(s).
>
>   ...
>   5 Oct 16:41:17 ntpd[5696]: synchronized to 64.125.78.85, stratum 1
>   5 Oct 16:51:38 ntpd[5696]: time reset -2.140133 s
>   5 Oct 16:56:40 ntpd[5696]: synchronized to 66.220.9.122, stratum 1
>   5 Oct 17:01:28 ntpd[5696]: synchronized to 64.125.78.85, stratum 1
>   5 Oct 17:07:20 ntpd[5696]: time reset -2.137760 s
>   5 Oct 17:11:49 ntpd[5696]: synchronized to 204.152.184.72, stratum 1
>    
This indicates that ntpd is actually stepping the time 2 seconds into 
the past approx every 900 seconds. So dovecot is correct that time has 
moved backwards. You need to stop time moving backwards :-).
[so not dovecot's fault, and likely not xen's fault either]

I'm no ntp expert, but I wonder if searching for 900s in the ntpd man 
page might help (caught my eye due to the step every 15 minutes - 
network congestion and excessive jitter causing stepping)? Otherwise 
perhaps a problem with a bad hardware driver stalling in the middle of 
an interrupt occasionally. Sorry - can't provide any further pointers. 
It is highly dependent on your hardware, kernel & drivers. If you have 
any other physical servers and they are also having 'time reset' error 
messages, then the problem is some odd network configuration - partial 
drop-outs and/or high jitter.

Unfortunately -x will not be a solution here as slew cannot possibly 
correct for a drift as big as 2 in every 900 seconds.

You may want to try just a single upstream ntp server as a debugging 
step (identify it by IP, not by a pool DNS record) and/or use the prefer 
keyword against your favourite.

Cheers,
Rob Middleton.


More information about the dovecot mailing list