Le 08/01/2023 à 12:53, Kevin P. Fleming a écrit :
On Sun, Jan 8, 2023, at 03:35, Iqbal Singh Aulakh -X (iaulakh - HCL AMERICA INC
at Cisco) wrote:
I can see from the dmesg log the eth1 port is up before the NTP
client/server is started:
demsg
[Fri Oct 28 05:09:45 2022] vmxnet3 0000:05:00.0 eth1: NIC Link is Up
10000 Mbps
[Fri Oct 28 05:09:45 2022] vmxnet3 0000:0b:00.0: # of Tx queues : 8, #
of Rx queues : 8
"Link is Up" means only that the layer 1 (physical) link has been established. It does
not mean that any addresses have been assigned to the interface or that any routes through it are
available. For example, if the interface is configured to use DHCP to obtain its network
information, it may be 5-30 seconds after "Link is Up" before the interface can actually
handle traffic.
At this point we can see chronyd continually retrying to connect to
both NTP sources, which is what is expected but for some reason it
marks the NTP sources as offline:
Oct 28 05:09:50 gsvlfl4plb02va chronyd[925]: 2022-10-28T05:09:50Z
ntp_io.c:316:(connect_socket) Could not connect NTP socket to
10.37.9.162:123 : Network is unreachable
The "some reason" is very clear: when chrony attempted to send a packet to
10.37.9.162 it got a reply from the network stack that no route to that address was
available.
I was hit by very slow stp resolution in some data centers and similar
timing dependent start-up problems on chrony and bind.
You must adapt your startup script or your systemd/systemd-networkd
dependence constraints because you do not want link up but ip and
routing (and perhaps next hop routing) available.
It is not a chrony defect.
Emmanuel.
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
