Re: [Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds
Hello,
You say ntpd is running. Is it running as a daemon ?
AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd".
I had _exactly_ the same problem and I was running an ntp daemon. I wasn't actually syncing to anything.
So,I did some searching and found out that I need to run "ntpdate ntp.server.fqdn", then add this same line to cron.
HTH,
s.
"I merely function as a channel that filters music through the chaos of noise"
- Vangelis
On 5.5.2011, at 20.45, Spyros Tsiolis wrote:
AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd".
No no no! That just makes things worse! It's the most common reason for these "Time jumped forwards/backwards" warnings.
--- On Thu, 5/5/11, Timo Sirainen <tss@iki.fi> wrote:
From: Timo Sirainen <tss@iki.fi> Subject: Re: [Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds To: "Spyros Tsiolis" <stsiol@yahoo.co.uk> Cc: f.bonnet@esiee.fr, "Dovecot" <dovecot@dovecot.org> Date: Thursday, 5 May, 2011, 21:49 On 5.5.2011, at 20.45, Spyros Tsiolis wrote:
AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd".
No no no! That just makes things worse! It's the most common reason for these "Time jumped forwards/backwards" warnings.
!
Seriously ?
.s
"I merely function as a channel that filters music through the chaos of noise"
- Vangelis
On 5/5/2011 1:54 PM, Spyros Tsiolis wrote:
--- On Thu, 5/5/11, Timo Sirainen<tss@iki.fi> wrote:
From: Timo Sirainen<tss@iki.fi> Subject: Re: [Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds To: "Spyros Tsiolis"<stsiol@yahoo.co.uk> Cc: f.bonnet@esiee.fr, "Dovecot"<dovecot@dovecot.org> Date: Thursday, 5 May, 2011, 21:49 On 5.5.2011, at 20.45, Spyros Tsiolis wrote:
AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd". No no no! That just makes things worse! It's the most common reason for these "Time jumped forwards/backwards" warnings.
!
Seriously ?
Definitely you should run ntpd -- but you need to make sure that it's configured correctly and working. Running "ntpdate" will cause time to jump.
-- Noel Jones
Quoting Noel <noeldude@gmail.com>:
On 5/5/2011 1:54 PM, Spyros Tsiolis wrote:
--- On Thu, 5/5/11, Timo Sirainen<tss@iki.fi> wrote:
From: Timo Sirainen<tss@iki.fi> Subject: Re: [Dovecot] May 05 07:20:21 imap: Warning: Time jumped
forwards 16 seconds To: "Spyros Tsiolis"<stsiol@yahoo.co.uk> Cc: f.bonnet@esiee.fr, "Dovecot"<dovecot@dovecot.org> Date: Thursday, 5 May, 2011, 21:49 On 5.5.2011, at 20.45, Spyros Tsiolis wrote:AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd". No no no! That just makes things worse! It's the most common reason for these "Time jumped forwards/backwards" warnings.
!
Seriously ?
Definitely you should run ntpd -- but you need to make sure that
it's configured correctly and working. Running "ntpdate" will cause
time to jump.
I thought everyone knew that if you removed the 1.55v watch battery
from the motherboard, you could put in a 1.6v battery and time will
run faster. Then just use ntpdate - time will never jump forward, and
dovecot won't crash.
:D
I had the same problem. If you are running dovecot on a virtual machine this is what I did and the issue was fixed:
http://nbevans.wordpress.com/2011/02/21/centos-5-5-losing-time-synchronisati...
On 5/5/2011 12:27 PM, Rick Romero wrote:
Quoting Noel <noeldude@gmail.com>:
On 5/5/2011 1:54 PM, Spyros Tsiolis wrote:
--- On Thu, 5/5/11, Timo Sirainen<tss@iki.fi> wrote:
From: Timo Sirainen<tss@iki.fi> Subject: Re: [Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds To: "Spyros Tsiolis"<stsiol@yahoo.co.uk> Cc: f.bonnet@esiee.fr, "Dovecot"<dovecot@dovecot.org> Date: Thursday, 5 May, 2011, 21:49 On 5.5.2011, at 20.45, Spyros Tsiolis wrote:
AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd". No no no! That just makes things worse! It's the most common reason for these "Time jumped forwards/backwards" warnings.
!
Seriously ?
Definitely you should run ntpd -- but you need to make sure that it's configured correctly and working. Running "ntpdate" will cause time to jump.
I thought everyone knew that if you removed the 1.55v watch battery from the motherboard, you could put in a 1.6v battery and time will run faster. Then just use ntpdate - time will never jump forward, and dovecot won't crash.
:D
Le 05/05/2011 à 21:27, Rick Romero a écrit :
I thought everyone knew that if you removed the 1.55v watch battery from the motherboard, you could put in a 1.6v battery and time will run faster. Then just use ntpdate - time will never jump forward, and dovecot won't crash.
:D
Hi,
As Timo just stated, you definitely should run ntpd, which tries to adjust the clock's pace smoothly, instead of ntpdate, which abruptly changes the clock and should only be used *before* starting ntpd (typically at service startup), to catch up a difference too big for ntpd to handle in a reasonable time.
If time moves backwards, Dovecot will not crash, but will kill itself, which in the end amounts to pretty much the same. ;-)
http://wiki2.dovecot.org/TimeMovedBackwards
Best regards,
Bruno
--
- Service Hydrographique et Oceanographique de la Marine - DO/MGS/INF
- 13, rue du Chatellier - CS 92803 - 29228 Brest Cedex 2, FRANCE
Phone: +33 2 98 22 17 49 - Email: Bruno.Treguier@shom.fr
On Thu, May 05, 2011 at 07:54:50PM +0100, Spyros Tsiolis wrote:
Seriously ?
Yes, Timo was (of course) both serious and correct.
ntpdate takes one or more NTP servers as parameters, and sets your server's time to match that of the NTP servers. That may well cause a jump, even a massive jump.
ntpd takes a list of NTP servers in its configuration file, and uses them to make continual small adjustments. I seem to remember that in some cases it is even capable of adjusting the speed of your system clock according to its measurements. If the difference is too great it will refuse to function and exit with an error.
The usual way is to run ntpdate with -b option once at boot (just after the network comes up and long before things like dovecot and MTAs get started), and then start up ntpd.
The other way is to run ntpdate frequently, against an NTP server you trust. It's not as good, but sometimes there may be objections against running daemons, and if you're aiming at a well-behaved NTP server the jumps should be minimal.
When running ntpd, the essential thing is to check that it's actually doing its job. You do that with the command "ntpdc". That will drop you to a prompt. The essential commands are
sysinfo
peers
server x.x.x.x
sysinfo
quitsysinfo should give your stratum as somwhere between 3 and 5 (if it's less you're probably doing something wrong, and if it's 16 you're not synchronized). peers should give one * sign in the first column and some number of + signs.
After that overview, man ntpdate, man ntpd, and google :-)
HTH.
On Thu, 5 May 2011 23:43:25 +0200 Lorens Kockum <dovecot.fdop@tagged.lorens.org> articulated:
On Thu, May 05, 2011 at 07:54:50PM +0100, Spyros Tsiolis wrote:
Seriously ?
Yes, Timo was (of course) both serious and correct.
ntpdate takes one or more NTP servers as parameters, and sets your server's time to match that of the NTP servers. That may well cause a jump, even a massive jump.
ntpd takes a list of NTP servers in its configuration file, and uses them to make continual small adjustments. I seem to remember that in some cases it is even capable of adjusting the speed of your system clock according to its measurements. If the difference is too great it will refuse to function and exit with an error.
The usual way is to run ntpdate with -b option once at boot (just after the network comes up and long before things like dovecot and MTAs get started), and then start up ntpd.
The other way is to run ntpdate frequently, against an NTP server you trust. It's not as good, but sometimes there may be objections against running daemons, and if you're aiming at a well-behaved NTP server the jumps should be minimal.
When running ntpd, the essential thing is to check that it's actually doing its job. You do that with the command "ntpdc". That will drop you to a prompt. The essential commands are
sysinfo peers server x.x.x.x sysinfo quit
sysinfo should give your stratum as somwhere between 3 and 5 (if it's less you're probably doing something wrong, and if it's 16 you're not synchronized). peers should give one * sign in the first column and some number of + signs.
After that overview, man ntpdate, man ntpd, and google :-)
HTH.
On a FreeBSD machine, putting the following two lines into the "/etc/rc.conf" file will cause "ntp" to be started and force it to synchronize the time regardless of how far out of sync it actually is.
ntpd_enable="YES" # Start time server ntpd_sync_on_start="YES" # Synchronize on start
Of course, you still need to have a default ntp.conf file.
-- Jerry ✌ Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
I did leave a little almost on-purpose dangling hint that got me an off-list query... Since I'm replying, I might as well reply on-list for the record, even if this is getting off-topic. I've just about exhausted my knowledge on the subject, so further questions will probably find a more attentive audience on some NTP list :-)
A reader wrote:
You wrote "probably" but isn't it common to sync against a stratum 1 server having some GPS clock attached? I assume that most computer centers operate a stratum 1 time server today and stratum of clients should be between 2 (!) and 5.
Most scientific computing centers maybe, but business people probably don't.
In my experience most people who run stratum-1 servers impose limitations on their clients, like asking for permission, registering, signing up for their mailing list, running public stratum-2 servers... or being in the same organization as them, which certainly seems to be your case :-)
I suppose the most common reason for restrictions like these would be that with more than n clients, the server will start having problems, bandwidth, latency, whatever. Maybe n is a large number, but then again maybe not, after all we're talking about milliseconds. I'm not sure what it would take to run a stratum-1 service with under one hundredth of second of jitter if that service gets used as the default for new Debian or RedHat installs, but I'm quite certain I don't want to pay for the hardware or the bandwidth! Registering for a mailing list is also important when the service is really really important.
You don't need to take my word for it:
http://support.ntp.org/bin/view/Servers/RulesOfEngagementAs for stratum-2 servers, there are lots of public ones with no restrictions other than running a reasonably well-behaved ntp implementation.
The difference being synced to a stratum-1 or a stratum-2 is negligeable; and most people who have reasons for milli-second accuracy want it between their own servers. They will run a set of NTP servers, stratum 1, 2 or 3, and sync all of their other servers to them. For many or even most uses it won't matter if they are a several milli-seconds off with respect to some atomic clock as long as they are internally consistent.
It is my opinion that someone like the OP, who wants his servers to be on time but who does not seem professionally interested in running an NTP server or in having milli-second accuracy, should not be peering with a stratum-1 server. That is the reason I wrote stratum-3 and not stratum-2 :-)
Just to be complete, on the other side of the spectrum, I think we agree that with such a lot of stratum-2 servers to choose from, it seems unnecessary to have a stratum above 5. You'd be at 5 if you sync to your organization's stratum-4 syncing to your ISP's stratum-3 syncing to public stratum-2s... maybe a multi-site organization would run an NTP service for every site, but then they'd probably sync their main servers directly to stratum-2 servers instead of to their ISP, so that'd cancel out.
HTH
Le 05/05/2011 20:49, Timo Sirainen a écrit :
On 5.5.2011, at 20.45, Spyros Tsiolis wrote:
AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd".
No no no! That just makes things worse! It's the most common reason for these "Time jumped forwards/backwards" warnings.
The machine runs FreeBSD not Linux :-) it runs ntpd pointing to several reliables NTP servers since 5 years
On 2011-05-06 12:05 AM, Frank Bonnet wrote:
Le 05/05/2011 20:49, Timo Sirainen a écrit :
On 5.5.2011, at 20.45, Spyros Tsiolis wrote:
AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd".
No no no! That just makes things worse! It's the most common reason for these "Time jumped forwards/backwards" warnings.
The machine runs FreeBSD not Linux :-)
So? The basic premise is still the same... the system clock should NEVER jump time like that during normal operations, if it does, something is seriously broken.
ntpdate, which causes large jumps, should only be used at boot time BEFORE server processes are started, then ntp CLIENT keeps the systems clock in sync using tiny increments, usually less than a second.
it runs ntpd pointing to several reliables NTP servers since 5 years
So something changed/broke? Happens all the time...
--
Best regards,
Charles
On Fri, 06 May 2011 06:53:13 -0400 Charles Marcus <CMarcus@Media-Brokers.com> articulated:
On 2011-05-06 12:05 AM, Frank Bonnet wrote:
Le 05/05/2011 20:49, Timo Sirainen a écrit :
On 5.5.2011, at 20.45, Spyros Tsiolis wrote:
AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd".
No no no! That just makes things worse! It's the most common reason for these "Time jumped forwards/backwards" warnings.
The machine runs FreeBSD not Linux :-)
So? The basic premise is still the same... the system clock should NEVER jump time like that during normal operations, if it does, something is seriously broken.
ntpdate, which causes large jumps, should only be used at boot time BEFORE server processes are started, then ntp CLIENT keeps the systems clock in sync using tiny increments, usually less than a second.
it runs ntpd pointing to several reliables NTP servers since 5 years
So something changed/broke? Happens all the time...
Sorry, I missed some of this thread; however, I was wondering if anyone suggested replacing the battery. I have seen a phenomena like this once before on an old PC with a dying battery.
I did post about a possible solution with ntp on a FreeBSD machine. I am not sure if the OP has tried that procedure or not.
-- Jerry ✌ Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
On 5/6/2011 5:53 AM, Charles Marcus wrote:
ntpdate, which causes large jumps, should only be used at boot time BEFORE server processes are started, then ntp CLIENT keeps the systems clock in sync using tiny increments, usually less than a second.
No, ntpd adjusts the clock frequency to keep the system in close sync with a reliable time source. To work properly, ntpd expects to be a long-running process so it can figure out the local clock drift and properly adjust it.
Anyway, drifting off topic here. Bottom line is that your server needs stable time, which ntpd can provide. Exceptions are virtual machines, which have their own time tools, and "personal" devices that sleep/resume frequently, AFAIK no reliable solution for these.
-- Noel Jones
participants (10)
-
Bruno Tréguier
-
Charles Marcus
-
Frank Bonnet
-
Jay Welch
-
Jerry
-
Lorens Kockum
-
Noel
-
Rick Romero
-
Spyros Tsiolis
-
Timo Sirainen