LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This 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


Reply
  Search this Thread
Old 07-30-2013, 09:18 PM   #1
isourabh.wadhwa
LQ Newbie
 
Registered: Jul 2010
Posts: 21

Rep: Reputation: 0
NTP high offset | no servers can be used, exiting


sudo /usr/sbin/ntpdate -q nxdbsr01.paramount.com
Code:
server 192.168.148.165, stratum 2, offset 45.247135, delay 0.09427
29 Jul 17:49:48 ntpdate[11404]: step time server 192.168.148.165 offset 45.247135 sec
sudo /usr/sbin/ntpdate -d nxdbsr01.paramount.com

Code:
29 Jul 17:49:54 ntpdate[11405]: ntpdate 4.2.0a@1.1190-r Thu May 13 04:29:07 EDT 2010 (1)
Looking for host nxdbsr01.paramount.com and service ntp
host found : nxdbsr01.paramount.com
transmit(192.168.148.165)
receive(192.168.148.165)
transmit(192.168.148.165)
receive(192.168.148.165)
transmit(192.168.148.165)
receive(192.168.148.165)
transmit(192.168.148.165)
receive(192.168.148.165)
transmit(192.168.148.165)
server 192.168.148.165, port 123
stratum 2, precision -20, leap 00, trust 000
refid [192.168.148.165], delay 0.09438, dispersion 0.00768
transmitted 4, in filter 4
reference time:    d5a18991.35bf5946  Mon, Jul 29 2013 17:38:41.209
originate timestamp: d5a18c60.e4c42635  Mon, Jul 29 2013 17:50:40.893
transmit timestamp:  d5a18c32.e169c23b  Mon, Jul 29 2013 17:49:54.880
filter delay:  0.09541  0.09489  0.09438  0.09535
         0.00000  0.00000  0.00000  0.00000
filter offset: 45.95513 45.96297 45.97070 45.97821
         0.000000 0.000000 0.000000 0.000000
delay 0.09438, dispersion 0.00768
offset 45.970707

29 Jul 17:49:54 ntpdate[11405]: step time server 192.168.148.165 offset 45.970707 sec
sudo /usr/sbin/ntpdate -U nxdbsr01.paramount.com

Code:
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 ?
 
Old 07-31-2013, 01:15 AM   #2
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 210

Rep: Reputation: 76
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.
 
Old 07-31-2013, 06:00 AM   #3
dt64
Member
 
Registered: Sep 2012
Distribution: RHEL5/6, CentOS5/6
Posts: 216

Rep: Reputation: 38
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.
 
Old 07-31-2013, 06:21 AM   #4
isourabh.wadhwa
LQ Newbie
 
Registered: Jul 2010
Posts: 21

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by mlslk31 View Post
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 View Post
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 ?
 
Old 07-31-2013, 07:37 AM   #5
dt64
Member
 
Registered: Sep 2012
Distribution: RHEL5/6, CentOS5/6
Posts: 216

Rep: Reputation: 38
Quote:
Originally Posted by isourabh.wadhwa View Post
will try this today .. and good point why on earth i am running ntpdate with ntpd on ..[COLOR="Silver"]

i would add the iburst today but is a reboot really required ? "service ntpd restart" wont work ?
of course
Code:
service ntpd restart
would do the trick as well.
 
Old 07-31-2013, 10:37 AM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,599

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
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.
 
Old 07-31-2013, 10:52 AM   #7
dt64
Member
 
Registered: Sep 2012
Distribution: RHEL5/6, CentOS5/6
Posts: 216

Rep: Reputation: 38
Quote:
Originally Posted by jpollard View Post
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?
 
Old 07-31-2013, 11:16 AM   #8
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,599

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
Quote:
Originally Posted by dt64 View Post
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.
 
Old 07-31-2013, 11:32 AM   #9
dt64
Member
 
Registered: Sep 2012
Distribution: RHEL5/6, CentOS5/6
Posts: 216

Rep: Reputation: 38
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.
 
Old 07-31-2013, 02:56 PM   #10
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 210

Rep: Reputation: 76
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.]

Last edited by mlslk31; 07-31-2013 at 02:58 PM.
 
1 members found this post helpful.
Old 08-05-2013, 01:41 AM   #11
isourabh.wadhwa
LQ Newbie
 
Registered: Jul 2010
Posts: 21

Original Poster
Rep: Reputation: 0
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 ..
 
Old 08-07-2013, 04:28 AM   #12
isourabh.wadhwa
LQ Newbie
 
Registered: Jul 2010
Posts: 21

Original Poster
Rep: Reputation: 0
iburst option didnt helped .. I made it back to config shown above .. anything else i can do ??

I dont know this well but someone told me by looking to ntpq o/p that my ntp servers also dont have same time .. how can I fix that ?
 
Old 08-07-2013, 07:07 PM   #13
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 210

Rep: Reputation: 76
What is the output of `ntpq -p -c rv` ?
 
Old 08-12-2013, 07:00 AM   #14
isourabh.wadhwa
LQ Newbie
 
Registered: Jul 2010
Posts: 21

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by mlslk31 View Post
What is the output of `ntpq -p -c rv` ?
right now it is okay(this issue), but it comes every 24 hours .. I'll post the o/p very soon
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
NTP offset value too high with ntpdate Rohit_4739 Linux - Newbie 1 04-04-2013 10:10 AM
ntp Offset value too high newcranium Linux - Server 3 05-20-2011 09:53 AM
[SOLVED] ntp - no servers can be used, exiting Wed Slackware 7 09-11-2010 08:44 AM
NTP high offset noir911 Red Hat 1 01-22-2009 09:34 AM
NTP offset marstse Linux - General 1 01-14-2009 01:33 AM


All times are GMT -5. The time now is 08:46 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration