Hi Alasdair,
On Thu, Jan 21, 2010 at 04:14:13PM +0000, Alastair Sherringham wrote:
Thanks Nigel. Note - ntpdate is happy to adjust this -
but dovecot
thinks this is bad and kills itself to prevent problems (
http://wiki.dovecot.org/TimeMovedBackwards).
This large time delta on boot is a big change from Debian Etch.
I'm sorry, I don't know why the host comes up with a large time
delta. I'll ask upstream and see if I can find out. On a normal
physical machine the host would take its system time from the
hardware clock, and most distributions set the hardware clock from
the system time when they shut down.
On a Xen domU using paravirtualization -- the current situation at
BitFolk -- there isn't any hardware clock. That's why there's a
message about failing to read the hardware clock during boot up.
That should be harmless though, because the host machine should
provide the domU with the correct time. The time is correct on all
the hosts; this is monitored.
As an aside, we can monitor your clock as well if you run an ntpd.
Just drop an email to support(a)bitfolk.com; monitoring of things with
Nagios is free.
I am not running NTP - just ntpdate (cron - set clock
once a day). Maybe I
shouldn't.
I would recommend that you do run ntpd because ntpdate will skew the
clock backwards if it needs to, and as you've seen many applications
don't like that.
ntpdate at (re)boot is a good idea.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting