Hi,
I have a set of servers whose system time is drifting. I am running ntp client on CentOS 5.8. My config is here -> http://fpaste.org/s55U/ Anything i am missing?
Regards,
Kaushal
On 06/04/12 12:59 PM, Kaushal Shriyan wrote:
I have a set of servers whose system time is drifting. I am running ntp client on CentOS 5.8. My config is here -> http://fpaste.org/s55U/ Anything i am missing?
whats the output of `ntptrace` ? are there entries about ntp in /var/log/messages ?
On Jun 4, 2012, at 1:59 PM, Kaushal Shriyan wrote:
Hi,
I have a set of servers whose system time is drifting. I am running ntp client on CentOS 5.8. My config is here -> http://fpaste.org/s55U/ Anything i am missing?
Fire up ntpq, and type "peers" and see if they're seeing their upstream servers. If not, hunt down the firewall or other filter problem.
Additionally, ntp will refuse to sync if it's too far out. Use ntpdate [server IP] to force the issue first. If the machines have a bad CMOS battery and won't keep time, ntpdate package can be configured to force time sync (which is a bad hack) at boot-time.
After getting the clock in sync, "hwclock --systohc" to push it into the CMOS clock.
Nate
On 06/04/12 1:27 PM, Nate Duehr wrote:
Additionally, ntp will refuse to sync if it's too far out. Use ntpdate [server IP] to force the issue first. If the machines have a bad CMOS battery and won't keep time, ntpdate package can be configured to force time sync (which is a bad hack) at boot-time.
the standard EL5 /etc/rc.d/init.d/ntpd script does this automatically, unless its been disabled via /etc/sysconfig/ntpd
After getting the clock in sync, "hwclock --systohc" to push it into the CMOS clock.
setting SYNC_HWCLOCK=yes in said above config file will do this, too.
On Jun 4, 2012, at 2:42 PM, John R Pierce wrote:
On 06/04/12 1:27 PM, Nate Duehr wrote:
Additionally, ntp will refuse to sync if it's too far out. Use ntpdate [server IP] to force the issue first. If the machines have a bad CMOS battery and won't keep time, ntpdate package can be configured to force time sync (which is a bad hack) at boot-time.
the standard EL5 /etc/rc.d/init.d/ntpd script does this automatically, unless its been disabled via /etc/sysconfig/ntpd
Interesting. I hadn't looked at the scripts in a while.
The reason no one ever did it "in the old days" was for fear of an NTP server going out of whack. ntpdate should be used sparingly and with knowledge that one is doing it... automating it is usually a bad idea. (Especially by default.) As I said in the original reply, it's a nasty hack.
IMHO, ntpdate package install should be just to get the tool installed, no automation. If it's installing automated setting by default, that's not right. One should have to turn ON automated ntpdate at startup/shutdown after understanding the risk.
After getting the clock in sync, "hwclock --systohc" to push it into the CMOS clock.
setting SYNC_HWCLOCK=yes in said above config file will do this, too.
Was just giving him the way to do it in real-time. The config file only does it at startup/shutdown, last I looked. Haven't looked recently.
Sounds like there's been some goofy decisions made somewhere along the line for ntp and ntpdate... an NTP server can be compromised and date/time changed across an envrionment (or more likely, it can have some type of failure itself...) and the old tenets of ntp were there for a reason...
1. ntp doesn't sync if it's too far out of whack... 2. ntpdate should be operated by hand... not automated...
Oh well. Those unwilling to learn from past mistakes are doomed to repeat them, right? (GRIN!)
Nate
On Mon, Jun 4, 2012 at 5:51 PM, Nate Duehr denverpilot@me.com wrote:
The reason no one ever did it "in the old days" was for fear of an NTP server going out of whack. ntpdate should be used sparingly and with knowledge that one is doing it... automating it is usually a bad idea. (Especially by default.) As I said in the original reply, it's a nasty hack.
Historically, hardware clocks that are way off at power up have been very common. It might better on current devices.
IMHO, ntpdate package install should be just to get the tool installed, no automation. If it's installing automated setting by default, that's not right. One should have to turn ON automated ntpdate at startup/shutdown after understanding the risk.
There's not too much risk from a big time jump at startup before most of your applications are doing anything. That seems much safer than waiting with a time difference that ntp itself won't fix and would take forever with it's fractional-second jumps if it tried.
Sounds like there's been some goofy decisions made somewhere along the line for ntp and ntpdate... an NTP server can be compromised and date/time changed across an envrionment (or more likely, it can have some type of failure itself...) and the old tenets of ntp were there for a reason...
Well, yes, but the cheap clocks and batteries in PCs are there for a reason too (not necessarily a good reason...) and that's what we've had to live with. I do usually run ntp on routers and sync from the ones nearby. Ciscos at least won't act as servers unless they are fairly confident about their own sources so there's not much chance of picking up a bad starting time. And you need to specify multiple servers to cover failures.
On Tue, Jun 5, 2012 at 1:57 AM, Nate Duehr denverpilot@me.com wrote:
After getting the clock in sync, "hwclock --systohc" to push it into the CMOS clock.
+1
On a PC Engines ALIX board (no battery backup for CMOS) that I am using as an WiFi AP, I have had to resort to a similar trick. Once at boot up and then every 20 mins from the system crontab.
-- Arun Khan
From: Arun Khan knura9@gmail.com
On Tue, Jun 5, 2012 at 1:57 AM, Nate Duehr denverpilot@me.com wrote:
After getting the clock in sync, "hwclock --systohc" to push it
into the CMOS clock.
+1
On a PC Engines ALIX board (no battery backup for CMOS) that I am using as an WiFi AP, I have had to resort to a similar trick. Once at boot up and then every 20 mins from the system crontab.
/etc/sysconfig/ntpd: # Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=yes
JD
On Mon, Jun 11, 2012 at 2:49 PM, John Doe jdmls@yahoo.com wrote:
From: Arun Khan knura9@gmail.com
On Tue, Jun 5, 2012 at 1:57 AM, Nate Duehr denverpilot@me.com wrote:
After getting the clock in sync, "hwclock --systohc" to push it
into the CMOS clock.
+1
On a PC Engines ALIX board (no battery backup for CMOS) that I am using as an WiFi AP, I have had to resort to a similar trick. Once at boot up and then every 20 mins from the system crontab.
/etc/sysconfig/ntpd: # Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=yes
Thanks; will try out in the ALIX box.
-- Arun Khan
-
Arun Khan -
John Doe -
John R Pierce -
Kaushal Shriyan -
Les Mikesell -
Nate Duehr