I have a Docker container based on Ubuntu 16.04 which runs the ntpd 4.2.8 service. Upon instantiation of the container, I've published the port 123/udp.
From the host or other computer on the LAN, I can use
ntpq -p <container_host> to get the list of peers and sync status. But monitoring it using collectd or running
ntpdc -c kerninfo <container_host> fails/timeouts. And this is puzzling me!
I've tested it inside the container with some reasonable
restrict statements and also without any. But in both cases I timeout. Running tcpdump in the container (after elevating it to privileged container) shows that the UDP packet arrives, but nothing is answered. Of course, using tcpdump I see both request and response when using ntpq which is working.
If I run the ntpd server on the host directly, using the same ntp.conf file, the
ntpdc -c kerninfo <container_host> and collectd both succeed from the host and other computers on the LAN I authorised! However, the host is still running an older version of Ubuntu (14.04) which ships with ntp 4.2.6.
So the only differences are the Docker networking (NAT as far as I understood) and the ntp version (4.2.6 vs 4.2.8). But the ntp.org documentation does not mention anything really about NAT nor about 4.2.8 updates. So is my command time-outing just because the client is on a different subnet than the server (due to NAT)? Or as something changed in 4.2.8?
Note: my container image is based on ubuntu:16.04 which runs ntpd email@example.com (from the Ubuntu official repositories). The host runs Ubuntu 14.04 which runs 4.2.6p5.
PS: Collectd submit a command equivalent to the
ntpdc -c kerninfo <container_host> and timeout when ntpd runs in the container, even is all the restrict statement are correct.
Update: I forgot to mention that I also did run the ntpd inside the container with the
-ddd option to get a more verbose output. The only relevant data that were logged are:
read_network_packet: fd=19 length 192 from 192.168.1.3 receive: at 26 172.17.0.2<-192.168.1.3 flags 19 restrict 000
Update2: After finding out the solution, I've changed the question hoping that other stumbling on the same problem might better find the question/answer when searching for it. I also corrected one mistake, I thought the host was running Ubuntu 16.04 but it was actually still running 14.04.