Alastair Sherringham wrote: Yeah, I understand, as long as the ntp rc script starts up before dovecot then by the time dovecot is up and running things should be fine. Lots of things get unhappy if the time apparently changes underneath them. Did you have ntpd running on that machine? Either way, I'd still recommend ntpdate/ntp. For example, it also takes acre of situations where, for example, a desktop machine's battery has died and it is no longer keeping time when powered down. Ah, yes, that might do it. I would suggest you run ntpdate once only on bootup to get the time correct so that ntp can then keep your clock from slewing too far out of alignment from then on. n

2010/1/21 Andy Smith <andy(a)bitfolk.com> Andy, Looks like this has been a problem in the past. Digging briefly (first/second hit) pinted me to a Debian bug + patch : Bug#517808: dovecot-common: please call ntp-wait before starting Dovecot http://www.mail-archive.com/debian-bugs-closed@lists.debian.org/msg218224.h… Fixed in dovecot-common 1.1.11-3 (Squeeze/Backports). A patch to the init script to do an ntp-wait. I'll sort something out. Maybe use the backport repo. Cheers, -- Alastair Sherringham

Hi Alastair, On Tue, Feb 16, 2010 at 11:57:22AM +0000, Alastair Sherringham wrote: Are you using clocksource=jiffies on the kernel command line? What is /proc/sys/xen/independent_wallclock set to? Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

Hello, On Tue, Feb 16, 2010 at 06:57:08PM +0000, Joseph Heenan wrote: The first thing I would try is having a kernel command line that looks like this: kernel /boot/vmlinuz-2.6.26-2-xen-686 root=UUID=d3249498-3e26-42c5-99a8-73fdd7ebcacb clocksource=jiffies ro console=hvc0 along with /proc/sys/xen/independent_wallclock=1 and running ntpod, this works fine for hundreds of Debian and Ubuntu VPSes running 2.6.2x Xen kernels. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting <Ging> i stopped taking my medication long ago. the ironey is it was for social anxioty disorder and now i daren't go back to the doctor to get another perscription

On 16 February 2010 19:18, Joseph Heenan &lt;joseph(a)heenan.me.uk&gt; wrote: Look in /var/log/syslog - from a boot until the end. Mine starts 30 mins ahead until near the end, then jumps forward (assuming a "bad" boot) : e.g. see attached for an example - notice time jump. I'll try Andy's jiffies, wallclock and ntpd suggestion ... reboot a few times again :-) -- Alastair Sherringham

Hi Joseph, On Tue, Feb 16, 2010 at 07:18:37PM +0000, Joseph Heenan wrote: That's where the usual boot scripts attempt to read the hardware clock (i.e. the BIOS) to get the system time from it. Xen paravirtual machines don't have hardware clocks so this always fails, and is harmless. As long as you have xen.independent_wallclock set to 1 then you should be able to set your clock yourself. If you don't then you won't be able to change it at all. It will just fail silently. I recommend that you set that to 1, run ntpd and put in a support ticket to support(a)bitfolk.com for me to monitor your ntpd for you. You'll know then if it ever loses sync. I do find that the clock is sometimes set oddly after boot or after a suspend/restore, but I am able to fix it with ntpdate and keep it synced with ntpd. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

On 16 February 2010 20:11, Alastair Sherringham &lt;sherringham(a)gmail.com&gt; wrote: Here's the syslog from the bad reboot. -- Alastair Sherringham

Hi Alastair, On Tue, Feb 16, 2010 at 08:16:36PM +0000, Alastair Sherringham wrote: I appreciate that time went backwards here which upsets dovecot, but.. You're now synced to an NTP server and have the correct time. Does it later lose sync? Is it possible that what you describe as an "OK" boot had independent_wallclock set to 0 so you were unable to set the time, it remained wrong, and dovecot did not complain? Personally I would rather have the right time and make dovecot start after ntpdate. Having it boot with the wrong time and then have ntpdate/ntp adjust it is the best I can offer I'm afraid, because that's the best I've been able to achieve. Just in case you might be thinking that the host you're on has the wrong time: kahlua$ date && ntpq -np Tue Feb 16 20:47:13 UTC 2010 remote refid st t when poll reach delay offset jitter ============================================================================== +209.237.247.192 212.13.195.4 4 u 770 1024 377 140.306 0.702 0.091 212.13.195.3 212.13.204.4 3 u 900 1024 377 0.280 2.328 0.271 212.13.195.4 212.13.204.4 3 u 910 1024 377 0.364 1.133 7.864 2001:ba8:1f1:f0 212.13.204.4 3 u 764 1024 377 4.560 0.207 1.500 2001:ba8:1f1:f0 212.13.204.4 3 u 767 1024 377 0.336 0.264 0.739 *212.13.204.4 195.66.241.10 2 u 29 1024 377 0.496 2.619 1.066 +212.13.204.5 195.66.241.2 2 u 989 1024 377 0.559 -0.330 0.066 So I don't know why it would be consistently around 35 minutes off. I do note that: kahlua$ date && hwclock --show && uptime Tue Feb 16 20:49:59 UTC 2010 Tue 16 Feb 2010 21:08:23 UTC -0.710159 seconds 20:50:00 up 349 days, 2:02, 5 users, load average: 0.52, 0.89, 1.23 which is obviously about 20 minutes off, but the hardware clock will get set from the system clock next time it's shut down, and I can't imagine why it would be used for anything. I'll sync it from the system clock now, though. kahlua$ sudo hwclock --systohc && date && hwclock --show Password: Tue Feb 16 20:51:53 UTC 2010 Tue 16 Feb 2010 20:51:54 UTC -0.472518 seconds Does that change things? Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting Of course not. Everyone knows you can't have your kayak and heat it. -- James Fidell

Andy Smith wrote: Ah, okay - so long as I've not broken anything then I'm happy :-) (and I've not seen the weird kern.log message since adding the clocksource=jiffies.) Thanks Joseph