Re: RE: Chrony is making NTP Server offline on the system boot

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-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]