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][1], 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][2] looks like another duplicate without a good answer.
[1]: https://serverfault.com/questions/266892/synchronizing-time-with-only-one-ntp-server
[2]: https://serverfault.com/questions/129703/ntpstat-response-fine-but-server-time-out-of-sync