I'm running dovecot on an OpenBSD 3.7 server and after upgrading to
RC25, the daemon started exiting with:
Fatal: Time just moved backwards (1173221579 -> 1173221578)! This
might cause a lot of problems, so I'll just kill myself now.
After upgrading to RC26, I've gotten the error:
Error: Time just moved backwards by 1 seconds. I'll sleep now until
we're back in present.
Occasionally, however, it's followed by:
Fatal: Sleep interrupted, byebye.
The server is running NTP, but I can't find any reason why it would have
to roll the clock back a second so often. Until I get this figured out,
I've gone back to RC19.
Any ideas? Thanks.
--
Emmett "Buddy" Pate
Chief Technology Officer
William E. Wood and Associates, Realtors
epate at williamewood.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070307/eb758595/attachment.html>
On Wed, 7 Mar 2007, Emmett Pate wrote: ****** snipped ******> The server is running NTP, but I can't find any reason why it would have to > roll the clock back a second so often. Until I get this figured out, I've > gone back to RC19.Hi Emmett, I had some servers that somehow "loses" time after a while and ntpd always had to resync. The problem went away after I replaced the onboard Lithium battery. Have you tried replacing the battery? Cheers.
On Wed, 2007-03-07 at 08:22 -0500, Emmett Pate wrote:> Occasionally, however, it's followed by: > > Fatal: Sleep interrupted, byebye.I thought this would never happen, so I didn't bother handling it. But this'll fix it: http://dovecot.org/list/dovecot-cvs/2007-March/007979.html> The server is running NTP, but I can't find any reason why it would > have to roll the clock back a second so often. Until I get this > figured out, I've gone back to RC19.I guess your clock doesn't stay on time somehow. No idea why.. But I found this from ntpd(8): -x Ordinarily, if the time is to be adjusted more than 128 ms, it is stepped, not gradually slewed. This option forces the time to be slewed in all cases. Note: Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus an adjustment of many seconds can take hours or days to amortize. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070307/f061feca/attachment.bin>
I'm currently running a VPS which has the NTP daemon running on neither my CentOS installation nor on the hardware node itself, so as far as I am aware the server time shouldn't be being resynched by anything, and the time should be consistent. However, since r25 my Dovecot service is complaining that time is moving backwards (was being killed only a few moments after being started with r25, same problems as Emmett with r26) quite consistently, and always by one second. Could this simply be an error or something within Dovecot itself, as to have nothing physically updating the system time on my machine at all and to have Dovecot complaining that it's being resynched by one second all the time seems a bit odd? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://dovecot.org/pipermail/dovecot/attachments/20070307/44af739a/attachment-0002.html>
On 09/03/2007 10:46, Matthew wrote:> Turns out it was a problem with the gettimeofday() function on my OS > install, has now been updated and Dovecot r26 runs fine.You said your OS was CentOS, and I run CentOS too, so please could you point me in the direction of this fix? Cheers, John.