Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So, I'm trying to debug my current NTP setup, and found that he offset from my single configured server is over 3 seconds, and not adjusting. The asterisk on the LOCAL(0) in the ntpq output seems to indicated that the system is happily syncing with itself rather than the 10.130.33.201 server (which is another linux box on our system that we want everything to sync to).

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

And this is my ntp.conf file. Written by someone else, so I'm not 100% sure that everything is correct.

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

I've read about the burst and iburst and minpoll/maxpoll, so I realize that those might not be needed, but I don't think that has anything to do with my current issue.

Also, because of how it is deployed, that config file will take a lot of work to change, so I hope that there's nothing that really must be changed. I'm hoping that this is a case of me not understanding how NTP works.


EDIT -

So, it looks like this is a duplicate of This question, but I don't feel that poster got a sufficient answer, so I would still like to know why the local time is being preferred over the server. Also, as per one of the answers below, I tried to use the prefer keyword on the server line of the config and restart, but that does not seem to have had an effect.

If I do remove all of the "local" lines in the config as the answer to the other question suggest, what will happen if the server is unreachable? Does NTP die or does it just keep trying?


IMPORTANT EDIT --

Ok, normally, 10.130.33.201 (The "server") has no access to the internet, and does not have a GPS time source to use. The important part is that all the devices on the system have the same time as the server, regardless of how correct that time actually is.

So, just to see what would happen, I added one of the NTP pool servers to the config file of the server so it would get time from there rather than getting time from local. It now correctly gets time from the NTP time server.

After I did that, the clients now sync with the server rather than prefering LOCAL(0)

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

NEW QUESTION - When my server is using local (original example that was given), it seems like the clients are saying, "Oh, 10.130.33.201 is using LOCAL(0). Hmm, I also have a LOCAL(0) server -- I'll just use that directly rather than getting the same information via 10.130.33.201".

Is that the case? Are they trying to go "directly to the source" which is incorrectly LOCAL(0)? I need my server to get time from LOCAL(0), and I need the clients to get time from the server. Right now removing the "local" server from the client config files is the only option, but I would like to understand why this is happening, and if at all possible, avoid changing their configs (config change will be a lot of work because of our environment...).

Also, this looks like another duplicate without a good answer.

share|improve this question
    
Also, if you have always-on network access to 10.130.33.201 consider removing the local clock source. –  Aaron Copley Jan 25 '13 at 18:53
add comment

3 Answers

It looks to me like the interval of offset (difference between your system time and that of the NTP hosttime) is too far different for NTP to properly set it.

My suggestion,

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

You should have no problems after that.

share|improve this answer
2  
If the machine happens to be a VM or have some other condition that causes it to come up with seriously broken time you can set the ntp tinker panic 0 option to force NTP to accept any offsets. But only use this with NTP servers you are certain will never return bad time. –  Zoredache Jan 25 '13 at 18:03
    
Ok, I thought that it had to be more than 1000s off before that was a problem, and then I thought that the server would be listed with a # sign? Is that not the case? Is "offset" in seconds or milliseconds? –  JPhi1618 Jan 25 '13 at 18:40
    
It won't sync to 10.130.33.201 right now because the offset is too high, but this won't fix the fact that it's drifting enough in the first place that LCL is becoming more desirable. I think this, a working driftfile, and prefer would do the trick. –  Aaron Copley Jan 25 '13 at 20:24
    
Could you explain why the offset is too high? It's less than 1000s (way less) and there is no # sign. Also, I have verified the actual time on both systems, and they are about 4 seconds apart. –  JPhi1618 Jan 25 '13 at 21:02
    
+/-1000 ms ... not +/-1000 s. It's at -3742 ms. –  Aaron Copley Jan 29 '13 at 17:00
show 1 more comment

With only one NTP server configured, the algorithm isn't entirely sure who to trust. Even though, stratum is lower with the remote host, I bet the algorithm thinks local time is more trustworthy.

Try using the prefer keyword with your server statement to set that as a preferential time source.


EDIT -

So, it looks like this is a duplicate of This question, but I don't feel that poster got a sufficient answer, so I would still like to know why the local time is being preferred over the server.

For a truly sufficient answer, you are going to be digging into the bowels of a very complex algorithm. The documentation doesn't even get too specific but I am sure there's a white paper or specification out there.

If I do remove all of the "local" lines in the config as the answer to the other question suggest, what will happen if the server is unreachable? Does NTP die or does it just keep trying?

The NTP daemon doesn't die or stop, but it does quit synchronizing time after it fails to reach the remote server. This is why best practices will suggest minimum of three remote servers and not to use the LCL unless you are disconnected from the network. Three servers are suggested because when there are only two, and they disagree, which will it choose? The third server should help the algorithm eliminate the bogus server.

Lastly, I just noticed that you do not define a driftfile. This might help?

share|improve this answer
    
Does making the difference between the two strata(ums?) influence this at all? Would having the server lower than 9 help? –  JPhi1618 Jan 25 '13 at 18:50
    
It might. Admittedly, I don't know a whole lot about the internals of the algorithm itself. However, the only case where you should fudge stratum is with local clock. I can't recommend that you fudge a remote server as a fix. NTP should be trusted to determine the best source with minimal interference. You just happen to have a case where you do need to give it a little push. –  Aaron Copley Jan 25 '13 at 18:54
    
Thanks for the suggestions. There was a driftfile, but it was not being created so I removed to see what would happen. Removing the local line does make it sync with the server, so that's something. You say that ntpd will "quit synchronizing time after it fails to reach the remote server", but will it start again after the server is reached? I just want to be safe in the case of a temporary network interruption. –  JPhi1618 Jan 25 '13 at 20:13
    
No, it won't start again. It just gives up. This is annoying and has been a catch-22 for me, too. We know now to restart NTP if network connectivity has been lost. Your driftfile is likely not being created because ntp doesn't have permissions to the path. Double-check that. –  Aaron Copley Jan 25 '13 at 20:18
add comment

The stratum of 10.130.33.201 as LOCAL server is 9, which makes the local stratum calculated from this (9+1=10) compete with the local LOCAL server at stratum 10. Since the local LOCAL stratum has no network delays or jitter, it may look slightly better to ntpd than the remote one.

If you want this config to work, set the 'master' LOCAL server to a stratum lower than 9. Not too low if you want a time traceable to a stratum 1 server to be preferred.

share|improve this answer
    
Thanks. I will check this out as soon as I can. Looks promising. –  JPhi1618 Feb 1 '13 at 18:18
    
Well, looks like I previously tried to lower the stratum of the 10.130.33.201 LOCAL server. Currently, it is set to 5, the client sees it as 6, but still prefers it's own LOCAL which has a stratum of 10. This configuration has been in place for days. –  JPhi1618 Feb 1 '13 at 19:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.