Mark
asked on
linux ntpd not working correctly
I've recently installed slackware distro 14.1. I'm having trouble with ntpd. The time on my computer is always off. The first time it was off 12 hours. I reset the time using `ntpdate -s time.nist.gov`. After rebooting, it is was off again, this time 4 hours. I've enabled ntpd on 3 other Debian systems and had no problem. According to /var/log/messages, ntpd is running. My TZ is set correctly to EDT.
What's wrong?
What's wrong?
ASKER
This is not a virtual machine. Other ideas?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Actually, I think I need to properly configure my ntp.conf file. I find the documentation on this wonderfully confusing. I want to set up to synchronize with server pool.ntp.org, and permit only hosts on 192.168.0.0/24 to synchronize with this host. What should I set in ntp.conf?
I believe I can accomplish the 1st goal by uncommenting the "#server pool.ntp.org iburst" line in ntp.conf. As to permitting hosts, the following is currently set in ntp.conf:
I believe I can accomplish the 1st goal by uncommenting the "#server pool.ntp.org iburst" line in ntp.conf. As to permitting hosts, the following is currently set in ntp.conf:
# Don't serve time or stats to anyone else by default (more secure)
restrict default noquery nomodify
# Trust ourselves. :-)
restrict 127.0.0.1
I've read about default noquery and nomodify options. The documentation appears to be written in English, but I confess I'm mystified as to its meaning. How do I permit only hosts on 192.168.0.0/24 to synchronize with this host?
you need to enter server x.x.x.x parameter to sync with and i would suggest to use iburst iburst with it..
Apart from this there is not much check with
#ntpq -np
TY/SA
Apart from this there is not much check with
#ntpq -np
TY/SA
ASKER
I've got:
server pool.ntp.org iburst
server 127.127.1.0 # local clock
and that appears to be working. I set my time off by +10 minutes last night and now it is back to the correct time. ntpq -p gives me:$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 6h 64 0 0.000 0.000 0.000
*repos.lax-noc.c 216.218.254.202 2 u 695 1024 377 69.032 0.777 2.003
but my question was not about syncing with the ntp server, I want to know what directive I need to let other hosts on the 192.168.0.0/24 LAN sync with *this* host. I believe I need a "restrict" directive, but can't figure out what that should be. Currently the restrict directives are set to the as-shipped defaults:restrict default noquery nomodify
# Trust ourselves. :-)
restrict 127.0.0.1
What do I need to let LAN member hosts sync with this host?
This is fine.. You can start using this as a NTP server for your LAN client ? configure and see...
TY/SA
TY/SA
ASKER
OK - will set up a client and post back results.
ASKER
Well, sorry to be a bad penny - but this just isn't working and I can't figure out why. All of the above worked just fine until I rebooted. Now, I'm back to having my system time 4 hours ahead of the real time and the ntpd daemon did not start (or at least I can say it is not currently running). I really need to know how to fix this. I don't get why this simple facility is such a problem. I have it running fine on Ubuntu and Debian, but Slackware is giving me fits! Help!
Hi Mark,
What happened to your Q where /include/sys was not saved to backup and it transpired you had dumped a 64-bit SW install over a 32-bit system? I can no longer find it, but never got a mail that it was to be deleted.
As to this Q, it sounds to me like your hardware clock is local time but Linux is configured to expect it to be UTC, or vice versa.
ntp generally exits when the time difference is more than the panic threshold (default 1000s; documented at file:///usr/doc/ntp-4.2.6p 5/html/mis copt.html# tinker ). When invoked with the -g option, a huge gap is allowed once; see -g, --panicgate in man ntpd. Perhaps some process is doing hwclock --hctosys after ntpd has started. That would kill ntpd but it should have logged something in /var/log/ntp.log
If you correct the setting of your hardware (BIOS) clock, all should be well.
What happened to your Q where /include/sys was not saved to backup and it transpired you had dumped a 64-bit SW install over a 32-bit system? I can no longer find it, but never got a mail that it was to be deleted.
As to this Q, it sounds to me like your hardware clock is local time but Linux is configured to expect it to be UTC, or vice versa.
ntp generally exits when the time difference is more than the panic threshold (default 1000s; documented at file:///usr/doc/ntp-4.2.6p
If you correct the setting of your hardware (BIOS) clock, all should be well.
I was saying the same. :D
Ty/SA
Ty/SA
ASKER
Duncan Roe: > What happened to your Q where /include/sys was not saved to backup and it transpired you had dumped a 64-bit SW install over a 32-bit system?
That question was/is: https://www.experts-exchange.com/questions/28493144/problems-installing-openchange.html, and perhaps you did find it after all because yours is the most recent response.
Duncan Roe, Sandy: I don't think the hardware clock as a timezone component and my local timezone is set to EDT. I will reboot and check the hardware clock setting this afternoon and report back.
That question was/is: https://www.experts-exchange.com/questions/28493144/problems-installing-openchange.html, and perhaps you did find it after all because yours is the most recent response.
Duncan Roe, Sandy: I don't think the hardware clock as a timezone component and my local timezone is set to EDT. I will reboot and check the hardware clock setting this afternoon and report back.
Check the contents of /etc/adjtime. If the last line of that file is UTC, that is your problem: the kernel expects a UTC BIOS clock but yours is EDT
ASKER
Duncan Roe: The last line of /etc/adjtime is "LOCAL".
Not sure what the problem is here. I set the hardware clock to the correct time and verified it a couple of days later by looking at the actual BIOS settings. After running for several weeks I rebooted a couple of times. I didn't notice a problem with the first couple of reboots, but when I just rebooted again my system time was set to +4 hours from the correct time and the hardware clock was set to +4 hours from that. I reset the hardware clock again and reset the system clock from the hardware clock (hwclock -s) and rebooted. Time is OK.
I don't know if I have a flakey hardware clock or what. I've used ntpd on other Debian systems w/o problem. This is my only Slackware running ntpd. OS? Hardware?
I'll scratch my head on this for a couple of days and if nothing interesting, I'll close it and eventually try on different hardware and see if I have the same problem.
Not sure what the problem is here. I set the hardware clock to the correct time and verified it a couple of days later by looking at the actual BIOS settings. After running for several weeks I rebooted a couple of times. I didn't notice a problem with the first couple of reboots, but when I just rebooted again my system time was set to +4 hours from the correct time and the hardware clock was set to +4 hours from that. I reset the hardware clock again and reset the system clock from the hardware clock (hwclock -s) and rebooted. Time is OK.
I don't know if I have a flakey hardware clock or what. I've used ntpd on other Debian systems w/o problem. This is my only Slackware running ntpd. OS? Hardware?
I'll scratch my head on this for a couple of days and if nothing interesting, I'll close it and eventually try on different hardware and see if I have the same problem.
similarly i was stating in comment #I40218571
ASKER
I've come to the conclusion that it must be my hardware. This seems to happen after a power outage which probably means the CMOS battery is not keeping the clock up to date -- however, it doesn't lose other settings. I'll close this out and will eventually change hardware.
TY/SA