Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
29 Jul 17:50:01 ntpdate[11409]: no servers can be used, exiting
sudo /usr/sbin/ntpq -pn
Code:
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.148.165 128.138.141.172 2 u 31 64 377 69.683 33347.4 19119.3
10.40.143.51 69.25.96.13 2 u 26 64 377 0.350 46917.9 29341.6
10.40.143.52 69.25.96.13 2 u 28 64 377 0.342 14097.4 19138.5
192.168.148.40 129.6.15.29 2 u 21 64 377 69.682 7680.91 23931.3
*127.127.1.0 LOCAL(0) 10 l 26 64 377 0.000 0.000 0.001
cat /etc/ntp.conf:
Code:
# restricted by default
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
# permit access from loopback interface
restrict 127.0.0.1
restrict -6 ::1
# time servers
server nxdbsr01.paramount.com
server nxinfp02.paramount.com
server nxinfp03.paramount.com
server nxinfr04.paramount.com
# local clock
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# drift file
driftfile /var/lib/ntp/drift
sudo /usr/bin/ntpstat && echo $?
Code:
sudo /usr/bin/ntpstat && echo $?
synchronised to local net at stratum 11
time correct to within 75 ms
polling server every 64 s
0
I am facing this frequently on many of my production servers in my enviroment ..
what could be the prob. ? how could I get this resolved ?
Beats me. I don't use ntpdate and thought it was deprecated in favor of `ntpd -q`. I use `ntpd -g`, which allows the first adjustment to be big, then leave the program running. While ntpd is running, I've never used ntpdate and don't know what would happen if I did. BTW, leave ntpd running: It increases the chances of ntpd working well later.
While debugging this, get rid of those restrict lines. Add parts of it back, keyword by keyword, until ntpd is broken again, restarting ntpd after each change to ntp.conf. You're reaching your servers just fine. Either your offset is too large, and `ntpd -g` might be the solution, or your restrict lines are too restrictive for ntpd to get sync off of those servers. You might also brew up separate restrict lines for the servers you're trying to reach.
you could add the iburst parameter to your server config lines, e.g.
Code:
server nxdbsr01.paramount.com iburst
This would make it sync to the server's time even the allowed offset is too big for a normal sync. Since this would happen only once ntpd is started (which should normally only happen when the machine is started) this shouldn't hurt too much.
Beats me. I don't use ntpdate and thought it was deprecated in favor of `ntpd -q`. I use `ntpd -g`, which allows the first adjustment to be big, then leave the program running. While ntpd is running, I've never used ntpdate and don't know what would happen if I did. BTW, leave ntpd running: It increases the chances of ntpd working well later.
While debugging this, get rid of those restrict lines. Add parts of it back, keyword by keyword, until ntpd is broken again, restarting ntpd after each change to ntp.conf. You're reaching your servers just fine. Either your offset is too large, and `ntpd -g` might be the solution, or your restrict lines are too restrictive for ntpd to get sync off of those servers. You might also brew up separate restrict lines for the servers you're trying to reach.
will try this today .. and good point why on earth i am running ntpdate with ntpd on ..
---------- Post added 07-31-13 at 03:52 PM ----------
Quote:
Originally Posted by dt64
you could add the iburst parameter to your server config lines, e.g.
Code:
server nxdbsr01.paramount.com iburst
This would make it sync to the server's time even the allowed offset is too big for a normal sync. Since this would happen only once ntpd is started (which should normally only happen when the machine is started) this shouldn't hurt too much.
i would add the iburst today but is a reboot really required ? "service ntpd restart" wont work ?
I use ntpdate before starting ntpd (ntpdate can't work while ntpd is running).
ntpdate gets my clock correct even if the battery is weak/bad - and then I maintain the clock using ntpd.
I can't see the advantage of using your version compared to use the iburst param. The downside of starting ntpdate first and start ntpd later is that you might have to do your own scripting or even manual hands on since usually ntpd would start at boot time as a service.
Could you please explain the background why you would prefer your way of doing?
I can't see the advantage of using your version compared to use the iburst param. The downside of starting ntpdate first and start ntpd later is that you might have to do your own scripting or even manual hands on since usually ntpd would start at boot time as a service.
Could you please explain the background why you would prefer your way of doing?
Depends on the system. Mine already had both available - so I just enabled both. ntpdate runs first, ntpd maintains the clock afterwards.
The problem with iburst is that it leave holes in the clock during normal operation (as in a restart of ntpd). It also introduces problems if your clock runs fast for some reason (or accident) and can set the clock backwards, causing logs to repeat time stamps (same with ntpdate, but ntpdate has to be done manually, using iburst ntpd does it every time ntpd starts). But other than that, there is no significant difference I can see other than the burst of ntp traffic when it starts (and still takes 10 seconds).
Running ntpdate at the very beginning at boot time logs the date change, and what did it. Since it is obvious from the log that it is during the boot, the amount of bogus log time stamps is minimized.
Other than that, I've been doing this nearly forever, and before the iburst option was available.
Alright, thanks for your explanation.
I agree that a random <service ntpd restart> could make the system time jump when using iburst, but in normal operation this service shouldn't be restarted too often while the system is running fine.
On the other hand ntpd should keep your system time always sync'd to the time source, so even a ntpd restart shouldn't cause a big difference, given that a ntpd restart shouldn't last more than a few seconds. I guess you have to look into other more serious issues first if you system clock runs more then 10 seconds ahead or behind withing the time the service restarts...
The point last point may really kick in if needed: log entries from ntpdate. If I remember right (I don't have an example at hand) ntpd only logs start and which time server it is using but not what it did to the system clock.
One thing I forgot: There's always the chance that Linux is using a bad clocksource. If you let ntpd run for, say, half an hour, and the output of `ntpq -c 'rv 0 frequency'` shows a number around 500.000 while the offsets shown by `ntpq -p` just get larger and larger, then your clock is not within the frequency range that default ntpd can discipline. Not all is lost--the different Linux clocksources have different frequencies, and I've seen clunker PCs where ntpd can discipline the acpi_pm timer but not the TSC, and vice versa--but it will take extra tinkering. ntpd itself has an extra tinker directive somewhere for this. Also, you should be able to change the tick rate of the Linux software clock using `adjtimex --tick [tick_number]`, bringing the number up or down until it comes within that 500ppm range that ntpd can discipline. Best case scenario is that `ntpq -c 'rv 0 frequency'` be a number between -50 and 50. [If you have trouble with `ntpq -c 'rv 0 frequency'`, then just type `ntpq -c rv` and sift through all that information manually.]
Oh my god .. so many replies .. here everyone is trying to help me and I did not had email notifications on .. sorry guys .. give me 15 minutes to read your replies ..
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
