Is there a package to do this?
Normally the hardware clock is set during shutdown if one is running ntpd. But if a long-running server shuts down unexpectedly, this isn't done, and the hardware clock might be off by a lot when it comes back up. So setting it periodically from a cron job could be useful.
What do others do? Adding a one liner to /etc/cron.daily that invokes /etc/rc.d/init.d/ntpd would do it but it seems heavyweight to restart ntpd. Alas, the script doesn't export just the sync_hwclock function.
I add this to /etc/rc.local
/usr/sbin/ntpdate us.pool.ntp.org
Sets the clock on start up. Might run it by cron once a month or so too.
On 03/04/11 12:40 PM, Matt wrote:
I add this to /etc/rc.local
/usr/sbin/ntpdate us.pool.ntp.org
Sets the clock on start up. Might run it by cron once a month or so too.
thats just the wrong way to go about it. if your clock is running fast, your cronjob will set it backwards, which will cause some interesting anomalies in anything time based, could cause a cronjob to trigger twice, funny timestamps in emails, etc.
just setup NTP and forget about it, and it will always work right, unless your system is really badly broken, whereupon, it would be better to fix it than to continue to hack around like this.
John R Pierce wrote:
On 03/04/11 12:40 PM, Matt wrote:
I add this to /etc/rc.local
/usr/sbin/ntpdate us.pool.ntp.org
Sets the clock on start up. Might run it by cron once a month or so too.
thats just the wrong way to go about it. if your clock is running fast, your cronjob will set it backwards, which will cause some interesting anomalies in anything time based, could cause a cronjob to trigger twice, funny timestamps in emails, etc.
just setup NTP and forget about it, and it will always work right, unless your system is really badly broken, whereupon, it would be better to fix it than to continue to hack around like this.
Yup. And if you look in your logs, if the system is gracefully shut down, it syncs the hardware clock with the system time.
mark
On Friday, March 04, 2011 03:54:21 pm John R Pierce wrote:
just setup NTP and forget about it, and it will always work right, unless your system is really badly broken, whereupon, it would be better to fix it than to continue to hack around like this.
For the sake of the archives, VMware guests should be set to sync from the host using the VMware tools functionality, and then the host should run NTP, even and especially on ESX. VMware timekeeping in the guest can be made worse by running NTP inside the guest. This is a well-known VMware issue, and is covered in depth on the VMware knowledgebase.
On 3/4/2011 3:59 PM, Lamar Owen wrote:
On Friday, March 04, 2011 03:54:21 pm John R Pierce wrote:
just setup NTP and forget about it, and it will always work right, unless your system is really badly broken, whereupon, it would be better to fix it than to continue to hack around like this.
For the sake of the archives, VMware guests should be set to sync from the host using the VMware tools functionality, and then the host should run NTP, even and especially on ESX. VMware timekeeping in the guest can be made worse by running NTP inside the guest. This is a well-known VMware issue, and is covered in depth on the VMware knowledgebase.
If you happen to have a server that gains time instead of loses it, note that a quick set to a time in the past will trigger an automatic shutdown of dovecot by dovecot due to fears of logging issues. I have two such machines... the rest lose time.
John Hinton
Lamar Owen wrote:
On Friday, March 04, 2011 03:54:21 pm John R Pierce wrote:
just setup NTP and forget about it, and it will always work right, unless your system is really badly broken, whereupon, it would be better to fix it than to continue to hack around like this.
For the sake of the archives, VMware guests should be set to sync from the host using the VMware tools functionality, and then the host should run NTP, even and especially on ESX. VMware timekeeping in the guest can be made worse by running NTP inside the guest. This is a well-known VMware issue, and is covered in depth on the VMware knowledgebase.
Excuse me? The last time I was following this closely, and I think the last time I looked, about a year ago, they said the opposite, that the guest, if running Linux, should use ntp.
Right: NTP Recommendations Note: In all cases use NTP instead of VMware Tools periodic time synchronization. Also, you may need to open the firewall (UDP 123) to allow NTP traffic. at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
mark
On Friday, March 04, 2011 04:05:43 pm m.roth@5-cent.us wrote:
Excuse me? The last time I was following this closely, and I think the last time I looked, about a year ago, they said the opposite, that the guest, if running Linux, should use ntp.
Right: NTP Recommendations Note: In all cases use NTP instead of VMware Tools periodic time synchronization. Also, you may need to open the firewall (UDP 123) to allow NTP traffic. at
Argh, they've changed it..... Last I read that page the recommendation was opposite to that. Although I remember the clock=pit part of that, and the divider=10 piece....
But I remember a couple of years ago reading the opposite about NTP....
Oh well, just goes to show that best practices change, although I have had fairly good results from VMware with the VMware tools sync, where I did not at that time have good results with NTP in the guest. On ESX 3.0.x and later ESX 3.5.
Well, time to go redo some things, I guess. We have a GPS-disciplined physical box as one of the three NTP masters we use....
On 03/04/11 12:59 PM, Lamar Owen wrote:
On Friday, March 04, 2011 03:54:21 pm John R Pierce wrote:
just setup NTP and forget about it, and it will always work right, unless your system is really badly broken, whereupon, it would be better to fix it than to continue to hack around like this.
For the sake of the archives, VMware guests should be set to sync from the host using the VMware tools functionality, and then the host should run NTP, even and especially on ESX. VMware timekeeping in the guest can be made worse by running NTP inside the guest. This is a well-known VMware issue, and is covered in depth on the VMware knowledgebase.
yeah, definately, VM of any sort is a whole different beast, and no way NTP should be run in a virtualized environment.
-
compdoc -
John Hinton -
John R Pierce -
Lamar Owen -
m.roth＠5-cent.us -
Matt