Re: [Dovecot] dovecot and ntp: Fatal: Time just moved backwards
Hi Timo,
Date: Tue, 9 Jun 2009 09:40:20 -0700 From: Timo Sirainen tss@iki.fi
On Jun 8, 2009, at 11:40 PM, Arno Wald wrote:
Timo Sirainen wrote:
Hmm. I suppose I could change Dovecot master so that if no imap/ pop3 processes have been created yet, it would silently ignore the clock move.
Also it might be an idea to just restart dovecot instead of completely stopping it. If this happens to often in a certain time interval it still could be stopped to avoid too many restarts in a loop if there is an error situation somehow.
http://wiki.dovecot.org/TimeMovedBackwards bottom answers this. A restart isn't much better than just ignoring the time change.
But really, all this leads is that admin has to detect the dovecot termination and simply go and restart it manually -- after some bad thoughts. I think that a config option to restart silently (or simply kill all connected imap/pop3 instances) would be quite reasonable. Basically it is the only thing I don't like in Dovecot... and was even planning to hack the time check out of the code =))
Best wishes Eugene
On Jun 9, 2009, at 1:03 PM, Eugene wrote:
But really, all this leads is that admin has to detect the dovecot
termination and simply go and restart it manually -- after some bad
thoughts.
Or the admin actually permanently fixes the time.
Timo wrote:
On Jun 9, 2009, at 1:03 PM, Eugene wrote:
But really, all this leads is that admin has to detect the dovecot
termination and simply go and restart it manually -- after some bad
thoughts.Or the admin actually permanently fixes the time.
This is usually a startup issue and the fact that so many OSes get this wrong and that dovecot complains about it so strongly points out this "rough edge".
H
On Jun 9, 2009, at 1:54 PM, Harlan Stenn wrote:
Timo wrote:
On Jun 9, 2009, at 1:03 PM, Eugene wrote:
But really, all this leads is that admin has to detect the dovecot termination and simply go and restart it manually -- after some bad thoughts.
Or the admin actually permanently fixes the time.
This is usually a startup issue and the fact that so many OSes get
this wrong and that dovecot complains about it so strongly points out this "rough edge".
And I already mentioned in this thread that I could try to get that
fixed:
Hmm. I suppose I could change Dovecot master so that if no imap/pop3
processes have been created yet, it would silently ignore the clock
move.
Hello
From: "Timo Sirainen" tss@iki.fi
But really, all this leads is that admin has to detect the dovecot termination and simply go and restart it manually -- after some bad thoughts. Or the admin actually permanently fixes the time.
In most cases we talk about, it can't be fixed permanently because this happens after (cold or warm) system restart, when ntpd can take up to 15 minutes (and in most cases about 3-5 minutes) to actually resync the time.
And since people are forced to restart Dovecot anyway, despite terrible warnings, and then nothing bad happens, people get the feeling that the problem is really artificially complicated =)
Regards Eugene
Eugene wrote:
In most cases we talk about, it can't be fixed permanently because this happens after (cold or warm) system restart, when ntpd can take up to 15 minutes (and in most cases about 3-5 minutes) to actually resync the time.
If you have a good drift file and use iburst (as discussed at http://support.ntp.org/bin/view/Support/StartingNTP4 and also at http://support.ntp.org/bin/view/Support/ConfiguringNTP) ntpd will have your clock sync'd in about 11 seconds' time.
H
On Wed, Jun 10, 2009 at 01:01:28AM +0400, Eugene wrote:
Hello
From: "Timo Sirainen" tss@iki.fi
But really, all this leads is that admin has to detect the dovecot
termination and simply go and restart it manually -- after some bad
thoughts. Or the admin actually permanently fixes the time.In most cases we talk about, it can't be fixed permanently because this
happens after (cold or warm) system restart, when ntpd can take up to 15
minutes (and in most cases about 3-5 minutes) to actually resync the time.
With chrony it can be fixed, almost.
What chrony does, besides acting as an NTP client when online, is to compare the hw clock to the system clock (kept in time via ntp) and determine the offset and rate of the hardware clock.
When you start up your computer with chrony's -r -s options, it reads the file, and corrects the time read from the harware clock according to the offset and rate error of the hardware clock.
The hardware clock rate changes by ppm so this is not perfect, e.g. if the computer is off for a week, it may well be out by a second, but of course if you did not do the rate correction it could be out by 10-100 sec.
regards Juergen
--
Juergen Daubert | mailto:jue@jue.li
Korb, Germany | http://jue.li/crux
Hi Eugene,
But really, all this leads is that admin has to detect the dovecot
termination and simply go and restart it manually -- after some bad
thoughts. During normal operation, on 99% of the hosts, the clock should never need to leap backwards. So if that ever happens, it seems fine for dovecot to stop and require admin intervention. This is perhaps not ideal, but it sure beats dovecot making mails disappear or doing other funky and undefined stuff.
If you happen to have a system on which this is in fact common, then you should find some way to deal with this yourself, preferably by not making the time leap backwards :-)
I'm not saying there shouldn't be any improvements to handle this in dovecot, but I think it's not so trivial to handle this properly, without risking data loss (as Timo pointed out, immediately restarting is not really helping, since you'll still be running in the past. AFAIU, dovecot should at least wait with restarting until the backwards leap time has passed again, which seems rather non-trivial to implement).
Gr.
Matthijs
Matthijs Kooijman wrote:
but I think it's not so trivial to handle this properly, without risking data loss (as Timo pointed out, immediately restarting is not really helping, since you'll still be running in the past.
It would be interesting (as I do not know anything about the dovecot internals) why the current time is so important for dovecot. In my simple thinking the mail server has to manage a set of mails that all have a time stamp. Why is the time that the mail server is running in important for this management?
Thanks, Arno
On 6/10/2009, Arno Wald (arno.wald@netcologne.de) wrote:
Why is the time that the mail server is running in important for this management?
No offense, but are you serious? If so, I certainly hope you aren't running a public mail server.
--
Best regards,
Charles
Charles Marcus wrote:
On 6/10/2009, Arno Wald (arno.wald@netcologne.de) wrote:
Why is the time that the mail server is running in important for this management?
No offense, but are you serious?
Well, I really meant the question seriously. A server gets mails, stores them and delivers them again, regardless of the current time. The only thing that is logical for me in case of a wrong time setting is, that the retrieval time stamp will be wrong. But why has a mail server a problem in handling mails with a future time stamp?
If so, I certainly hope you aren't running a public mail server.
No I do not. Mail server/handling and network configuration is one of the big magics for me.
--
Backward time steps can cause real problems for Maildir, as its "uniqueness" algorithms can be ... theoretically correct.
H
On 6/9/2009, Eugene (genie@geniechka.ru) wrote:
Basically it is the only thing I don't like in Dovecot... and was even planning to hack the time check out of the code =))
That would not be a good idea.
You are chasing a symptom (the way dovecot responds to a serious problem), instead of the problem. Maintaining correct time is absolutely critical on a server, *especially* a mail server. Fix the problem - why 'time just moved backwards' keeps happening - and the dovecot 'symptom' goes away.
In most cases we talk about, it can't be fixed permanently because this happens after (cold or warm) system restart, when ntpd can take up to 15 minutes (and in most cases about 3-5 minutes) to actually resync the time.
I see that Harlan already addressed why this is only true if you haven't done your homework.
--
Best regards,
Charles
participants (7)
-
Arno Wald
-
Charles Marcus
-
Eugene
-
Harlan Stenn
-
Juergen Daubert
-
Matthijs Kooijman
-
Timo Sirainen