On Thu, 2 Apr 2009, Charles Marcus wrote:
On 4/2/2009, Tom Diehl (tdi...@rogueind.com) wrote:
I see this all of the time on an EL4 machine when it is under high
load. The clock is synced to ntp but I still get dovecot killing
itself. Sometimes ntp looses sync but not always.
Hopefully you
Top posting has nothing to do with it, take your nazi'ism and put it
where someone else might care to listen :) If your name is in the To
field (even a 5yo can figure that one out) , then I responded to you,
and I've seen RH boxes before that dont play like that, hence my
suggestion.
On Fri,
On 4/2/2009 6:05 PM, Noel Butler wrote:
I see this all of the time on an EL4 machine when it is under
high load. The clock is synced to ntp but I still get dovecot
killing itself. Sometimes ntp looses sync but not always.
Hopefully you meant ntpd, not ntpdate... but I believe the OP was
On Fri, 2009-04-03 at 20:08, Charles Marcus wrote:
Hopefully you meant ntpd, not ntpdate... but I believe the OP was
using a VM, so ntpd is not an option...
How is that so? we use some vmware and xen setups, and ntpd works
fine on both
Hello,
I am experiencing a number of 'Time moved backwards errors' such as:
Mar 27 11:38:20 host-78-129-239-60 dovecot: imap-login: Time just moved
backwards by 729 seconds. This might cause a lot of problems, so I'll just kill
myself now. http://wiki.dovecot.org/TimeMovedBackwards
Mar 27
time should *never* move backwards. OSes (and programs) assume time is
always moving forward. Injure your VPS provider.
On 2009 Apr 02 (Thu) at 12:49:43 +0100 (+0100), Bloke wrote:
:Hello,
:
:I am experiencing a number of 'Time moved backwards errors' such as:
:
:Mar 27 11:38:20
On 2009 Apr 02 (Thu) at 12:49:43 +0100 (+0100), Bloke wrote:
Hello,
I am experiencing a number of 'Time moved backwards errors' such as:
Mar 27 11:38:20 host-78-129-239-60 dovecot: imap-login: Time just moved
backwards by 729 seconds. This might cause a lot of problems, so I'll just
On Thu, 2 Apr 2009, Mark Hedges wrote:
On 2009 Apr 02 (Thu) at 12:49:43 +0100 (+0100), Bloke wrote:
Hello,
I am experiencing a number of 'Time moved backwards errors' such as:
Mar 27 11:38:20 host-78-129-239-60 dovecot: imap-login: Time just moved
backwards by 729 seconds. This might
On 4/2/2009, Tom Diehl (tdi...@rogueind.com) wrote:
I see this all of the time on an EL4 machine when it is under high
load. The clock is synced to ntp but I still get dovecot killing
itself. Sometimes ntp looses sync but not always.
Hopefully you meant ntpd, not ntpdate... but I believe the
Why not just run ntpd and be done with it, ensure you start ntpd with
-g option
On Fri, 2009-04-03 at 03:11, Tom Diehl wrote:
On Thu, 2 Apr 2009, Mark Hedges wrote:
On 2009 Apr 02 (Thu) at 12:49:43 +0100 (+0100), Bloke wrote:
Hello,
I am experiencing a number of 'Time moved
On Fri, 2009-04-03 at 05:43, Charles Marcus wrote:
On 4/2/2009, Tom Diehl (tdi...@rogueind.com) wrote:
I see this all of the time on an EL4 machine when it is under high
load. The clock is synced to ntp but I still get dovecot killing
itself. Sometimes ntp looses sync but not always.
Why not just run ntpd and be done with it, ensure you start ntpd with
-g option
It's more than this. ntpd should be started ASAP in the boot process,
and then as late as possible in the boot process one should run
ntp-wait. Only after ntp-wait finishes should time-critical services be
OK..
So I synced the clock
and got
dovecot: Time just moved backwards by 1 seconds. I'll sleep now until
we're back in present. http://wiki.dovecot.org/TimeMovedBackwards
( The first time I did this the clock moved backwards 2 hours after a
timezone change and dovecot suicided )
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Feb 18, 2009 at 05:17:18PM +0200, Harry Lachanas wrote:
OK..
So I synced the clock
and got
dovecot: Time just moved backwards by 1 seconds. I'll sleep now until we're
back in present. http://wiki.dovecot.org/TimeMovedBackwards
to...@tuxteam.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Feb 18, 2009 at 05:17:18PM +0200, Harry Lachanas wrote:
OK..
So I synced the clock
and got
dovecot: Time just moved backwards by 1 seconds. I'll sleep now until we're
back in present.
Words by Harry Lachanas [Wed, Feb 18, 2009 at 05:17:18PM +0200]:
OK..
So I synced the clock
and got
dovecot: Time just moved backwards by 1 seconds. I'll sleep now until
we're back in present. http://wiki.dovecot.org/TimeMovedBackwards
( The first time I did this the clock
On Feb 18, 2009, at 10:17 AM, Harry Lachanas wrote:
dovecot: Time just moved backwards by 1 seconds. I'll sleep now
until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards
( The first time I did this the clock moved backwards 2 hours after
a timezone change and dovecot
on 2-18-2009 7:17 AM Harry Lachanas spake the following:
OK..
So I synced the clock
and got
How are you syncing the clock? The preferred method is to run ntpd to keep the
clock synced by nudging the timer faster or slower instead of doing large time
corrections.
dovecot: Time just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Feb 18, 2009 at 06:08:04PM +0200, Harry Lachanas wrote:
to...@tuxteam.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Feb 18, 2009 at 05:17:18PM +0200, Harry Lachanas wrote:
OK..
So I synced the clock
and got
Rob wrote:
Is this related to the leap second that occured yesterday?
There was no leap second in February.
H
on 2-18-2009 8:12 AM Rob Mangiafico spake the following:
On Wed, 18 Feb 2009, Harry Lachanas wrote:
OK..
So I synced the clock
and got
dovecot: Time just moved backwards by 1 seconds. I'll sleep now
until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards
Is this
On February 18, 2009 6:08:04 PM +0200 Harry Lachanas grha...@freemail.gr
wrote:
of course I do .
The server I was talking about was a test server, fresh install, and I
corrected the time zone
not possible. unix systems keep track of UTC time, not local time.
you may have changed the
Hi all,
I am running dovecot version 1.1.1 (dovecot --version) and keeps to have
time moved backwards problem.
I first found dovecot dead without obvious error message, but see the
following when restart dovecot service by
# service dovecot restart
Stopping Dovecot Imap: [FAILED]
Bill Cole wrote:
You might even be better off configuring your system to not use the
TSC as a clock source. There's a strong chance that you won't really
be sacrificing anything that you actually use.
Time to conclude on this.
Rather than going along with my Dovecot hack, I went and changed
Dovecot (v1.1.rc8) died tonight, with an error about time moving
backwards by 4398 seconds. I can see from logs that this has happend a
few times before with the imap processes, without me noticing. I sure
noticed the master process missing, though :-).
I was puzzled that it was always 4398
On Fri, 2008-06-20 at 10:53 +0200, Anders wrote:
Dovecot (v1.1.rc8) died tonight, with an error about time moving
backwards by 4398 seconds. I can see from logs that this has happend a
few times before with the imap processes, without me noticing. I sure
noticed the master process missing,
Johannes Berg [EMAIL PROTECTED] writes:
On Fri, 2008-06-20 at 10:53 +0200, Anders wrote:
I was puzzled that it was always 4398 seconds, in particular because
this server runs an NTP daemon. A little searching for this problem
shows that it is an issue with the Linux kernel gettimeofday(),
On Fri, 2008-06-20 at 10:53 +0200, Anders wrote:
Dovecot (v1.1.rc8) died tonight, with an error about time moving
backwards by 4398 seconds. I can see from logs that this has happend a
few times before with the imap processes, without me noticing. I sure
noticed the master process missing,
On Fri, 2008-06-20 at 11:10 +0200, Anders wrote:
Johannes Berg [EMAIL PROTECTED] writes:
On Fri, 2008-06-20 at 10:53 +0200, Anders wrote:
I was puzzled that it was always 4398 seconds, in particular because
this server runs an NTP daemon. A little searching for this problem
shows that
Johannes Berg wrote:
On Fri, 2008-06-20 at 11:10 +0200, Anders wrote:
Johannes Berg [EMAIL PROTECTED] writes:
On Fri, 2008-06-20 at 10:53 +0200, Anders wrote:
I was puzzled that it was always 4398 seconds, in particular because
this server runs an NTP daemon. A little searching for this
This bug causes Dovecot to run the IO loop in the future for one
iteration, and then die when we get back to present time.
By the time Dovecot dies, some damage could already have happend, for
example if ioloop_time is stored to permanent storage.
Hmm, ok, I was under the impression it
At 11:10 AM +0200 6/20/08, Anders wrote:
Johannes Berg [EMAIL PROTECTED] writes:
On Fri, 2008-06-20 at 10:53 +0200, Anders wrote:
I was puzzled that it was always 4398 seconds, in particular because
this server runs an NTP daemon. A little searching for this problem
shows that it is an
Bill Cole wrote:
At 11:10 AM +0200 6/20/08, Anders wrote:
By that line, the entire time moved backwards thing does not belong
in Dovecot.
I suspect that you don't understand why that is in Dovecot. Timo has
explained it in detail a few times, but the bottom line is simple:
running through
Bill Cole wrote:
At 10:20 PM +0400 5/14/08, Eugene wrote:
Hi people,
From: Adam McDougall [EMAIL PROTECTED]
I would just like to mention a circumstance that happened to me this
Sunday. We had a total power outage in our building, longer than our
UPS's could last and we don't have a generator
At 10:12 AM -0400 5/15/08, Neal Becker wrote:
Problem I see is that an external script that *unconditionally* relaunches
dovecot could be a terribly problem. It's better for dovecot to do it
itself in this particular failure, because it's the only one who knows that
it was just a date issue,
Hi people,
From: Adam McDougall [EMAIL PROTECTED]
I would just like to mention a circumstance that happened to me this
Sunday. We had a total power outage in our building, longer than our
UPS's could last and we don't have a generator for servers (nor is it
economical or needed). When the
At 10:20 PM +0400 5/14/08, Eugene wrote:
Hi people,
From: Adam McDougall [EMAIL PROTECTED]
I would just like to mention a circumstance that happened to me this
Sunday. We had a total power outage in our building, longer than our
UPS's could last and we don't have a generator for servers (nor
Hello,
I would like to suggest a change in handling of 'Time moved backwards'
problem.
Right now dovecot just dies. So, the scenario:
1) Colocation server is shut down for some reason. The internal time drifts.
2) Server is started again.
3) Dovecot starts successfully.
4) In about a minute,
On Tue, 2008-05-13 at 11:13 +0400, Eugene wrote:
I suggest that Dovecot simply terminate the current connections (causing the
client to reconnect) or -- if the time change is really that much of a
problem -- to restart itself automatically.
I guess terminating all current connections and
On 09:23:57 2008-05-13 Timo Sirainen [EMAIL PROTECTED] wrote:
On Tue, 2008-05-13 at 11:13 +0400, Eugene wrote:
I suggest that Dovecot simply terminate the current connections
(causing the client to reconnect) or -- if the time change is really
that much of a problem -- to restart itself
Hi Timo,
From: Timo Sirainen [EMAIL PROTECTED]
I suggest that Dovecot simply terminate the current connections (causing
the
client to reconnect) or -- if the time change is really that much of a
problem -- to restart itself automatically.
I guess terminating all current connections and
On Tue, May 13, 2008 at 11:13:39AM +0400, Eugene wrote:
Hello,
I would like to suggest a change in handling of 'Time moved backwards'
problem.
Right now dovecot just dies. So, the scenario:
1) Colocation server is shut down for some reason. The internal time drifts.
2) Server is started
Hello,
From: Quentin Garnier [EMAIL PROTECTED]
4) In about a minute, NTP daemon feels confident about adjusting the
system
time.
The admin should run ntpdate before launching ntpd and dovecot. ntpd
will _never_ move time backwards under normal drifting conditions (it
has other ways of coping
On Tue, May 13, 2008 at 11:39:54AM +0400, Eugene wrote:
Hello,
From: Quentin Garnier [EMAIL PROTECTED]
4) In about a minute, NTP daemon feels confident about adjusting the
system
time.
The admin should run ntpdate before launching ntpd and dovecot. ntpd
will _never_ move time backwards
On Tue, 2008-05-13 at 12:51 +0400, Anton Yuzhaninov wrote:
Timo Sirainen пишет:
On Tue, 2008-05-13 at 11:13 +0400, Eugene wrote:
I suggest that Dovecot simply terminate the current connections (causing
the
client to reconnect) or -- if the time change is really that much of a
On 10:48:28 2008-05-13 Eugene [EMAIL PROTECTED] wrote:
Hello,
From: Quentin Garnier [EMAIL PROTECTED]
I'm not the one having trouble reading, here. The proper way to
start a system is to run ntp*date* (as early as possible) and then
ntpd.
That's what you say, and it is far from being
Timo Sirainen пишет:
On Tue, 2008-05-13 at 11:13 +0400, Eugene wrote:
I suggest that Dovecot simply terminate the current connections (causing the
client to reconnect) or -- if the time change is really that much of a
problem -- to restart itself automatically.
I guess terminating all
Hello,
From: Quentin Garnier [EMAIL PROTECTED]
I'm not the one having trouble reading, here. The proper way to start a
system is to run ntp*date* (as early as possible) and then ntpd.
That's what you say, and it is far from being officially accepted.
NTP project clearly deprecates ntpdate
At 11:31 AM +0400 5/13/08, Eugene wrote:
Hi Timo,
From: Timo Sirainen [EMAIL PROTECTED]
I suggest that Dovecot simply terminate the current connections (causing the
client to reconnect) or -- if the time change is really that much of a
problem -- to restart itself automatically.
I guess
On 15:48:42 2008-05-13 Bill Cole [EMAIL PROTECTED]
wrote:
At 11:31 AM +0400 5/13/08, Eugene wrote:
Hi Timo,
From: Timo Sirainen [EMAIL PROTECTED]
I suggest that Dovecot simply terminate the current connections
(causing the client to reconnect) or -- if the time change is really
that much
At 11:13 AM +0400 5/13/08, Eugene wrote:
Hello,
I would like to suggest a change in handling of 'Time moved
backwards' problem.
Right now dovecot just dies. So, the scenario:
1) Colocation server is shut down for some reason. The internal time drifts.
2) Server is started again.
3) Dovecot
Nevertheless, it would be very nice if you could fix it. It's a
fairly big availability problem (for us, at least).
Then you have a badly broken system. There is no explanation for time
going backwards on a server on a frequent unplanned basis that is not
reducible to administrative
At 3:58 PM +0200 5/13/08, AndraÏ 'ruskie' Levstik wrote:
On 15:48:42 2008-05-13 Bill Cole [EMAIL PROTECTED]
wrote:
At 11:31 AM +0400 5/13/08, Eugene wrote:
Hi Timo,
From: Timo Sirainen [EMAIL PROTECTED]
I suggest that Dovecot simply terminate the current connections
(causing the client
At 12:48 PM +0400 5/13/08, Eugene wrote:
Hello,
From: Quentin Garnier [EMAIL PROTECTED]
I'm not the one having trouble reading, here. The proper way to start a
system is to run ntp*date* (as early as possible) and then ntpd.
That's what you say, and it is far from being officially accepted.
Charles Marcus wrote:
On 5/13/2008, Eugene ([EMAIL PROTECTED]) wrote:
I guess terminating all current connections and restarting all processes
would be pretty safe, but it's not really a high priority change for
me..
Nevertheless, it would be very nice if you could fix it. It's
on 5-13-2008 12:13 PM Adam McDougall spake the following:
Charles Marcus wrote:
On 5/13/2008, Eugene ([EMAIL PROTECTED]) wrote:
I guess terminating all current connections and restarting all
processes
would be pretty safe, but it's not really a high priority change for
me..
On 5/13/08 3:33 PM, Scott Silva wrote:
This would be a good case for running ntpdate on startup at least on
the ntp server. Just point it to a reliable outside server. AFAIR
RedHat and clones do this in the init script for ntpd.
...and how much more TIME shall we spend rechewing this
57 matches
Mail list logo
