As Chris mentioned, the stratum 16 indicates a server hasn't actually sync'd with a server. Just to be certain, you did restart the ntp services, right? (service ntpd restart) I'm not trying to insinuate you miss the easy stuff, but I always do!
Can you post the output of a few more commands to help diagnose?
ntpq -p on the client & server. Should show what servers it has configured, as well as stats for those servers.
ntpdc -c monlist on the server. Should show the clients connected.
Also, since you didn't mention an OS, I'm running with RHEL style commands. Let me know if you've got something different.
EDIT after further info
OK, seeing your output, here's your problem: You don't have a stratum 1 server. In fact, the "Moon" is using it's local clock. It's reporting itself as a stratum 16 server. For your reference, a Stratum1 server would have a local GPS or atomic clock. Do you have one of those? Otherwise, Moon needs to synchronize it's clock with ANOTHER ntp server. If it doesn't have network access, you'll need to fudge its stratum. (This requires you not to care too much about 'true' time. Which you don't, but anyone else reading this should note that.)
On Moon, add the following line to your ntp.conf file: fudge 127.127.1.0 stratum 10. This will make it report its local clock as stratum 10. Which will make all the other servers use it over their local stratum 16 clock.
--Christopher Karel
Your situation is unusual, and I'd be surprised if anyone comes up with a standard ntpd-based configuration to do what you want. That said, I like being surprised, and it happens quite often around these parts.
But until someone comes up with a better idea, have you considered a crontab entry like this?
*/5 * * * * ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )
IE, every five minutes try to sync the clock via ntpdate, and if (and only if) that fails, adjust the hardware clock for drift according to the /etc/adjtime file (whose format is detailed in man hwclock, and whose first line you have populated appropriately using your knowledge of that particular RTC's rate), then set the system clock from the RTC.
Note that if you go for a solution like this, and you are deploying any significant number of these systems, it is considered polite to work with the pool, and contribute servers back in proportion to your usage. You can find more information at http://www.pool.ntp.org/en/vendors.html .
Best Answer
Applications on general purpose compute cannot know in all cases how time sync works on the hosts they run on. In a container, you do not see and cannot connect to the chronyd or ntpd running on the host, yet this keeps time just fine. Or a VM guest that relies on host time sync, also not visible. Further making a general answer difficult, there are more NTP implementations than you might think: chrony, ntp, ntpsec, openntpd, w32tm.
Often documentation of the importance of correct time is sufficient.
On some platforms, making a dependency on an ntpd starting is relatively straight forward. On RHEL, to wait for time sync
systemctl enable chrony-waitand add to your systemd unitYet there are applications with strict time requirements. Most demanding I can think of is time stamping authorities, one of which claims standards require less than one second offset or nothing can be issued. This aggressive of a response implies the application does its own time checks.
Perhaps bundling a SNTP client, which checks NTP offsets in your application, against configurable NTP servers. Cannot check for a proper ntpd running, but can sanity check offsets regardless of how time sync works to the host.