Thank you for the prompt answers
@Luuk Vosslamber
finding correct values for the following entrys in your vmware(host) config file might solve some things: host.cpukHz = 1596000 <== depends on processor speed ;-) host.noTSC = TRUE ptsc.noTSC = TRUE hostinfo.noTSC = TRUE tools.syntime = TRUE
Above values go with the presumption that the host CPU is running at a fixed frequency. The variable frequency seems to be the origin of this problem..
We tried your parameters already, but they are not an option, unless you have the following a) machine smp disabled (enabled in our case) b) other machines on the host system have really low load c) vmware tools should not be missing on guest
@Peter Hessler
never ever ever run ntp on virtual hardware.
instead, run ntp on the host hardware, and tell the client to always obey the bios clock. I add "* * * * * /sbin/hwclock --localtime -->hctosys" to my crontab for that.
Thank you very much Peter, this hint opens up a bunch of new possibilities only mentioning "adjtimex" ...
BUT: And this brings me back to, why I posted this issue to the dovecot mailinglist and not elsewhere: All these guest based solutions lead to a fixed time movement (we used previously ntpdate -u every 7 minutes, ntp itself synchronizes every 11 minutes with the hardware clock for calculating drifts), which happens about once per week, that the time movement backward is larger than 11 seconds between two dovecot imap operations, which leads to an immediate shutdown of the dovecot process. All other services on these machine can cope with this.
So the question is how to get these adjustments smooth or close to realtime.
Best regards, Robert
Btw.: We are running Dovecot 1.0.13 from Debian etch-backports (which is an important information since debian seems to have its own rules ;) )