AW: AW: [chrony-users] Chronyd aborts when system time differs too much from chrony's measurements

[<thomas.schmid@xxxxxxxxx>]

Hi Bill,
>Have you tried the latest development version of chrony? Chrony did have a
>problem with its scheduling (ie, it would tell the system to wake up chrony at
>a certain time to for example run the next measurement, and the scheduler
>would get confused if the time changed significantly.) I believe that this is
>now supposed to be fixed, but you may be running into this bug in an older
>version.
No I have not tried this version. Need to get familiar with basic git first..

>> It sure should not crash. That is clearly a bug in chrony. When did this crash
>> happen? .. How far off was the system time when it happened?
> I found a difference in system time of 1h is enough most of the time.
>> When it finally found a time source?
> Very much possible, the system is still starting up, but routing had been started and the associated
> router should have sent a default route by then.
>> Do you have logs from before that crach and during that crash ( /var/log/chrony/measurements for example)
I have attached the logs from chrony when it crashed this morning: 
- I let chronyd run the whole night and do its measurements, then stopped chronyd, 
- set the system time back by 1h and wrote this new system time to the BIOS clock
using hwclock. This to simulate a time change by battery failing, as I have no
physical access to the test system now.
 
I did normalize the IP addresses in use: there are 2 WAN-based NTP servers 
(<WAN-IP>, <WAN-IP2>) and 1 LAN-based NTP server configured by hostname 
and resolved by a local DNS into <LAN-IP>. I also included the chrony entries from
syslog and the chrony.conf I am using.

Thomas Schmid

Attachment: chrony_aborts_recent_logs.tar.gz
Description: chrony_aborts_recent_logs.tar.gz