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
>
> http://support.ntp.org/bin/view/Su
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
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, 2
On Fri, 3 Apr 2009, Noel Butler wrote:
Why not just run ntpd and be done with it, ensure you start ntpd with
"-g" option
If you are responding to me (it is hard to tell when you top post) I am
running ntpd. I still have the problem described below. I have never used the
-g option but the Red H
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 mea
> 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
star
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
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
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
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 cause
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
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 host-78-129-23
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 15:20
On February 18, 2009 6:08:04 PM +0200 Harry Lachanas
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 time zone *and also*
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/TimeM
Rob wrote:
> Is this related to the leap second that occured yesterday?
There was no leap second in February.
H
-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 cloc
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
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 suici
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 clo
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 related to the leap second that occured yesterday?
Rob
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. http://wiki.doveco
-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/TimeMovedBack
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
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I followed the above official wiki link and apply the ntpd service for
> adjusting the server timestamp. After running the ntpd service, I found
> the server timestamp drift is only 14.333 microsecond, I think which
> would be reasonable.
That is
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]
>Sta
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 change
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
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
> 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
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 pro
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 proble
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 gettimeo
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,
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 second
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, an
On May 15, 2008, at 5:12 PM, 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 is
Here's another thought:
>From man ntpd:
If the -x option
is included on the command line, the clock will never be stepped and
only slew corrections
will be used.
The issues should be carefully explored before deciding to use
the -x option. The maximum
slew rat
> 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, and relaunching is safe.
But as Timo has
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
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
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 po
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 non-dove
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..
Never
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 a
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 accept
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
>>>(causin
>>> 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 administr
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
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 sta
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 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 a
> fairly big availability pr
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
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
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 curr
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
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_ mov
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 copi
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 star
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 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
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 an
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, NT
64 matches
Mail list logo
