And after a couple of minutes it changed again to 51120. But after a couple of minutes, when the next polling occurs: netstat -ulpvn | grep systemd Looks like 42212 is the port where the service expects the communication to happen. May 24 09:29:34 myhost systemd-timesyncd: Timed out waiting for reply from 91.189.91.157:123 ().įurther information about the port: netstat -ulpvn | grep systemd This, imo, pretty much proves that the ports are required. Note that there are no log entries inbetween for almost See the log of the systemd-timesync service (annotated by me with #): # Before I enabled the 32786+ ports The higher ports should not be necessary, but in my case, for some reason, they clearly are. Is opening that range of ports really necessary to operate systemd-timesync?Įdit in response to response below. Only after I also whitelisted the ephemeral UDP ports 32768–65535 in the firewall did this start to work: systemd-timesyncd: Initial synchronization to time server 91.189.91.157:123 (). Systemd-timesyncd: Timed out waiting for reply from 91.189.94.4:123 (). The service log was full of systemd-timesyncd: Timed out waiting for reply from 91.189.89.199:123 (). Then I read that using systemd-timesyncd is preferred nowadays, so I tried switching over to that. Through some trial and error I found out that in order for ntp to work, I have to open the incoming UDP port 123. The server is behind a cloud-provider-stateless firewall. I'm trying to get some sort of time synchronization configured for a Ubuntu server.
0 Comments
Leave a Reply. |