Daniel L. Miller wrote:

Stephen Feyrer wrote:

...

Hi Everyone.

Ooops I just broke my dovecot install.

I've looked through the mailing list archives and not found anything relevant.

When I try to connect to my mail server I get this message. "Could not connect to mail server chen.home.org; connection was refused"

The last message in /var/log/mail.err is:-

Aug 13 21:02:27 chen dovecot: Fatal: Time just moved backwards by 3603 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards

It seems this is my own fault. Time on my system is a little wonky so I reset the time and then I found out I'd broken Dovecot. I didn't realise that doing this would have an impact on dovecot. I read the web page and to be honest I'm not confident about hacking source code.

I've reinstalled dovecot which worked except it hasn't solved my time travel problem.

By the way since my first install of dovecot the config file seems to have changed a little but since I've tried to migrate my settings over the new file and been met with the same problem I don't think it's that.

Is it possible to get dovecot working again? What happens when you try to start Dovecot again? Not re-install - just start it.

I just did this to show you.

# /etc/init.d/dovecot restart

• Stopping dovecot ... [ ok ]
• Starting dovecot ... [ ok ]

And then this...

# dovecot -n # 1.1.1: /etc/dovecot/dovecot.conf listen: [::] ssl_ca_file: /etc/ssl.ca/myca.pem ssl_cert_file: /etc/ssl.ca/newcerts/email.cer ssl_key_file: /etc/ssl.ca/private/email.key ssl_cipher_list: ALL:!LOW:!SSLv2 ssl_verify_client_cert: yes verbose_ssl: yes login_dir: /var/run/dovecot/login login_executable: /usr/libexec/dovecot/imap-login mail_location: maildir:~/.maildir auth default: ssl_require_client_cert: yes ssl_username_from_cert: yes passdb: driver: pam args: * userdb: driver: passwd socket: type: listen client: path: /var/run/dovecot/auth-client mode: 432 master: path: /var/run/dovecot/auth-master mode: 384 user: root group: root

And then this again... # /etc/init.d/dovecot restart

• Stopping dovecot ... [ ok ]
• Starting dovecot ... Warning: Last died with error (see error log for more information): Time just moved backwards by 106 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards [ ok ]

I've not seen this before in a restart.

That was followed by... # /etc/init.d/dovecot restart

• Stopping dovecot ... [ ok ]
• Starting dovecot ... [ ok ]

-- Regards

Stephen.

On 8/15/2008, Daniel L. Miller (dmiller@amfes.com) wrote:

Um....do you have a UPS? If not - get one! Are you running running an ntp server? I'm assuming not. It's time to start.

He doesn't need an ntp server, he needs to be running an ntp CLIENT...

But first he needs to fix his hardware clock problem if this is a production server.

--

Best regards,

Charles

ntp client as a service (daemon) is the way to go... I had the same problem; I wasn't aware of the fact that dovecot would be sensitive to time going backwards. I was running ntpdate via cron, and the first time the time-check resulted in backwards correction, dovecot bombed. Unless the drift is great and frequent it's not a hardware clock problem as generally the clocks on the PC motherboard drift, and the drift doesn't have to be much when it's to the "wrong" direction (as far as dovecot is concerned). The way ntp handles the correction is very graceful—by speeding up or slowing down the clock (or stepping for greater corrections)—that it's recommended even on systems that don't run dovecot. If the drifts are generally nominal, it might be a good idea to use -x (--slew) option to allow adjustment of the common few second corrections more gradually without stepping. Without the "-x" option slew is limited to ±0.128 second corrections and time is stepped even for, say, 3 second corrections. With -x one second correction is completed in about 33 minutes, and greater corrections (up to 600 seconds) take thus days to complete, so the -x option is not good for systems with bad clocks :-).

Ville

on 8-18-2008 1:54 PM Charles Marcus spake the following:

On 8/18/2008, Ville Walveranta (walveranta@gmail.com) wrote:

...

ntp client as a service (daemon) is the way to go... I had the same problem; I wasn't aware of the fact that dovecot would be sensitive to time going backwards. I was running ntpdate via cron, and the first time the time-check resulted in backwards correction, dovecot bombed.

This is nothing new... time has *always* been considered extremely critical on servers - and ntpdate has *always* been seen as the WRONG way to keep a server in time - it moves time in much too large increments.

An ntp client has always been the way to go...

But you should also make sure your hardware clock is not totally crapped out, as that can make a [successful] cold start problematic...

During a cold start is probably the ONLY time ntpdate would be appropriate. Call ntpdate right after the network starts, but before the other services get started and your time should be very close. Then a ntp client can keep it that way.

-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!

OK, I admit I am new to LINUX, so please help me in setting up my server as NTP client. In the past, I have had the same problem where the time moved backward.

In my case I have only 1 server on which I run everything. Currently this server is setup to synchronize time using the NETWORK TIME PROTOCOL (application which comes with CentOS).

So here is my question: How do I setup this one server as NTP Client? You can point me to a location the NET, where I can read and set it up myself!

Kirt

-----Original Message----- From: dovecot-bounces+kbajwa=tibonline.net@dovecot.org [mailto:dovecot-bounces+kbajwa=tibonline.net@dovecot.org] On Behalf Of Ville Walveranta Sent: Monday, August 18, 2008 2:38 PM To: Dovecot Mailing List Subject: Re: [Dovecot] dovecot: Fatal: Time just moved backwards by 3603seconds.

ntp client as a service (daemon) is the way to go... I had the same problem; I wasn't aware of the fact that dovecot would be sensitive to time going backwards. I was running ntpdate via cron, and the first time the time-check resulted in backwards correction, dovecot bombed. Unless the drift is great and frequent it's not a hardware clock problem as generally the clocks on the PC motherboard drift, and the drift doesn't have to be much when it's to the "wrong" direction (as far as dovecot is concerned). The way ntp handles the correction is very graceful—by speeding up or slowing down the clock (or stepping for greater corrections)—that it's recommended even on systems that don't run dovecot. If the drifts are generally nominal, it might be a good idea to use -x (--slew) option to allow adjustment of the common few second corrections more gradually without stepping. Without the "-x" option slew is limited to ±0.128 second corrections and time is stepped even for, say, 3 second corrections. With -x one second correction is completed in about 33 minutes, and greater corrections (up to 600 seconds) take thus days to complete, so the -x option is not good for systems with bad clocks :-).

Ville