I have a setup with a host and a client which had that error.
The host used to work, it's a VM and somehow it break on my last reboot. Now it has a hard time to keep time in the "Default" paravirtualization. Instead I have to use the "Minimal" version which doesn't work as well (it takes forever to reboot because it has issues with time...)
The issue is that if the NTP server is not able to properly synchronize, then it gives up and "disconnect" itself.
Here is an example of a well behaved NTP server:
$ ntpq -pn
remote refid st t when poll reach delay offset jitter
1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.008
2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.008
3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.008
ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.008
+22.214.171.124 126.96.36.199 2 u 845 1024 377 83.321 -1.074 2.255
+188.8.131.52 .CDMA. 1 u 4 1024 377 15.626 -1.183 2.644
+184.108.40.206 220.127.116.11 2 u 980 1024 377 65.114 -1.463 3.575
+18.104.22.168 22.214.171.124 3 u 1012 1024 377 16.956 -0.740 1.862
*126.96.36.199 .GPS. 1 u 1016 1024 377 63.002 -1.160 3.213
-188.8.131.52 184.108.40.206 2 u 616 1024 377 150.713 1.133 2.524
What we notice is an entry marked
.GPS. which has an asterisk (
*) in the first column. That means that time server is the used currently used to adjust your computer's time.
If there are no line with the
*, then the NTP server is either not yet ready (it takes about 20 seconds on startup) or it tried to synchronize and wasn't able to. The
ntpdate tests will fail with:
ntpdate: no server suitable for synchronization found
whenever either of these states are found.
In case of a VM, you are not really supposed to use an NTP server. I have to because I'm virtualizing a system which uses an NTP server and it's very important in that simulation. You can have very similar issues with a VM as with a normal host, but the VM added the VirtualBox extra code... (additional details).
In case of a Host, there are three main issues:
- In most cases, you have a firewall which blocks port 123. Note that this is UDP so the data has to go out and come back in.
- The name of the time servers is invalid (unlikely if you kept the default).
- Your hardware clock is defective (I never had such a problem, but I've heard of such--so it is really rare).
To test my firewall, I add
LOG entries to tell me whether a hit is blocked. So before a
REJECT rule, I place a LOG rule with the same parameters. That allows me to look at the logs and see whether certain hits are blocked.
As a side note, on my end I send the iptables logs to a separate file
:msg,contains,"[iptables] " /var/log/iptables/iptables.log
This way I can avoid the clutter in the
/var/log/syslog and quickly find issues. The
"[iptables] " works because I prefix my
LOG messages with that string:
-A INPUT -i lo -j LOG --log-prefix "[iptables] reject_lo(in): " --log-uid
-A INPUT -i lo -j REJECT
If you can test without a firewall first, great, because that would be a lot faster to determine whether your firewall is the culprit. If you're not running any services on your computer, then that's safe:
$ sudo iptables -F