imap failing daily

mikelegg

Well-Known Member
Mar 29, 2005
330
3
166
OK .. here's my latest idea ...

UDP Port 123 wasn't open in CSF or our Cisco Firewall, so NTP wouldn't have been working anyway.

These ports have now been opened so I'll see if NTP will help keep the time on track and thus avoid the backwards problem.
 

mikelegg

Well-Known Member
Mar 29, 2005
330
3
166
This appears to have helped the problem somewhat.

I've been monitoring /var/lib/ntp/drift and the value began to decrease once the firewall was opened. Once the drift value got below 6 seconds the dovecot error messages in the log became
Code:
dovecot: dovecot: Time just moved backwards by 4 seconds. I'll sleep now until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards: 2 Time(s)
and IMAP didn't fail as it did with the previous error message
Code:
dovecot: dovecot: Fatal: Time just moved backwards by 7 seconds. This might cause a lot of problems, so I'll just kill myself now. 
http://wiki.dovecot.org/TimeMovedBackwards: 1 Time(s)
So I havent had an "imap failed" notification for a few days now.

Only two things still trouble me -

1) What is actually causing the sudden backwards time shifts (They only ever occur after hours when things like upcp and backups are running).

2) When I checked the drift file this morning it has a value of over 8 seconds, which to me indicates that NTP is fighting a losing battle against the sudden time shifts.

I've verified that my VPS isn't configured to sync time with the host machine, so it's got to be something within the virtual machine that's causing this.

When I review my upcp notification email I notice there is a line that says
Code:
Setting Clock......Done
Can anyone tell me what this is? Perhaps it has something to do with the backwards time shifts?
 
Last edited:

mikelegg

Well-Known Member
Mar 29, 2005
330
3
166
From what I can gather, the "Setting Clock" line refers to when the upcp script runs "rdate" which uses the Time Protocol, which "is generally considered obsolete and has been replaced by the Network Time Protocol (NTP)". (rdate - Wikipedia, the free encyclopedia)

So the question now is - how do I prevent upcp from resetting the clock?
 
Last edited:

mikelegg

Well-Known Member
Mar 29, 2005
330
3
166
I think NTP has fixed this problem for me.

Also, my comment above regarding the drift file is irrelevant - I misunderstood the purpose of the drift file value.

The accuracy of the clock will improve as NTP does it's thing and eventually when upcp runs rdate the changes will be smaller. They're already under the 5 second mark which makes dovecot happy.
 

Stallyon

Member
Sep 14, 2005
12
0
151
cPanel Access Level
Root Administrator
Sorry to bring up an old post, but I am under the impression that this is a Xen based Virtual environment known bug that is considered "out of scope" to be repaired. What is the best way to solve this? Will cPanel break if I update my dovecot to version 2.1.x, which doesn't seem to kill itself if there's a time skew?
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
41
348
somewhere over the rainbow
cPanel Access Level
Root Administrator
Please try what was suggested in that thread:

What you can do is Tell xen to give each dom-u an independent wallclock (echo 1 > /proc/sys/xen/independent_wallclock) and use jiffies instead of Xen as a clock source within the guests. This is an ugly fix, but it will prevent the time skew (going backwards) from triggering the kernel into thinking a bogus soft lockup happened. If you do this, make sure to run ntp within the guests.