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, NTP daemon feels confident about adjusting the system time. 5) Dovecot sees the changed time and dies. 6) Admin has to notice that, login and restart Dovecot manually. 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. Maybe a config option could be introduced. Best wishes Eugene
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 restarting all processes would be pretty safe, but it's not really a high priority change for me..> Maybe a config option could be introduced.There are too many settings already. -------------- 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/20080513/70c597da/attachment-0002.bin>
On 09:23:57 2008-05-13 Timo Sirainen <tss at iki.fi> 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 automatically. > ? > 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.. > > > Maybe a config option could be introduced. > > There are too many settings already.Or simply launch ntpd with the -s or whatever the appropriate switch to adjust time on bootup and ensure it starts pre-dovecot... -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Hi Timo, From: "Timo Sirainen" <tss at iki.fi>>> 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 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 problem (for us, at least). And after all, if we are terminating already, adding a simple spawn call before that should not take much time? Best wishes Eugene
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 again. > 3) Dovecot starts successfully. > 4) In about a minute, NTP daemon feels confident about adjusting the system > time. > 5) Dovecot sees the changed time and dies. > 6) Admin has to notice that, login and restart Dovecot manually.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 with that). -- Quentin Garnier - cube at cubidou.net - cube at NetBSD.org "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20080513/920b4bdf/attachment-0002.bin>
Hello, From: "Quentin Garnier" <cube at cubidou.net>>> 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 with that).Please read carefully. ntpd IS run before dovecot, but a change of time happens some time later. Of course, dovecot starting script can be hacked to sleep for some time, but it feels like a wrong way to solve a problem. Best wishes Eugene
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 current connections and restarting all processes > would be pretty safe, but it's not really a high priority change for > me..IMHO more robust is to use clock_gettime(CLOCK_MONOTONIC, ..) for timeouts and just work fine even if time was changed via settimeofday(). -- WBR, Anton Yuzhaninov Rambler Mail
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 starts successfully. >4) In about a minute, NTP daemon feels confident about adjusting the >system time.That's broken. Either your startup is running in the wrong order, it is missing a step, or your NTP daemon is misconfigured. This sort of problem is why some OS's default startup procedure is intentionally designed to block on 'ntpdate' running successfully. You are likely to be better off with a system that is obviously not working than one which started and then was subjected to a backwards clock change, which can harm more than Dovecot. -- Bill Cole bill at scconsult.com
Hi people,> From: Adam McDougall <mcdouga9 at egr.msu.edu> > 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 power came back on, my local NTP server > came on at the same time as my mail servers, as well a majority of my > other servers. My servers tried to step their time to be in sync with > my local NTP server, which was still busy trying to sync itself with > outside sources, which takes a while, so my mail servers did not get an > answer. Later, dovecot died because the time finally synced, and I > found out why pretty quick (have seen this before) but this was an > unusual situation. > > My point is, we had an unusual circumstance, and even though I've taken > steps to have my mail servers sync their time at boot and run ntpd > afterwards, there are some circumstances in which this is not enough, > and dovecot still died. Its not always because someone was lazy about > their time setup.My point exactly. It's amazing how some people are quick to ramble about someone else's administrative incompetence without taking time to read the situation. (One person even suggested hacking the dovecot startup script to run ntpdate -- useless as ntpd already occupies the ports). Fact is, ntpd can take unpredictable delay before the initial time-step. Delay that can't be controlled, and it would be unreasonable to delay starting mail services until it is guaranteed to complete. Then, dovecot dies, and admin (who is not always immediately available) has to start it manually anyway (especially as it is not clear what to do with possibly unsynced timestamps) -- only after the unnecessary downtime. So, the question is: why on earth can't we add a single line of code to dovecot to restart itself after terminating? Kind of reminds me of the "fsck_y_enable=YES" option in rc.conf. Without it, if fsck does not like someting during reboot, the server would just sit there in single-user prompt, waiting for (expensive) console operations. Best wishes Eugene