Thanks for your swift response. The no makestep is intentional indeed since we never want to 'step' the clock to avoid other sw issues. Looking further the problem seems related to gpsd itself. While trying to restart services and reproduce the issue, the issue never shows of course and gps timesync goes fine. But whenever the problem is there a 'systemctl status gpsd' reports me the service is inactive (dead). Although the process still shows in 'ps aux' and cgps and other gps-related processes still run fine... I'll try to see with gpsd debug flags what the issue is here... But in short, chrony is simply not getting any updates from gpsd (the shared memory segment also shows no gpsd attached, solely chronyd).
________________________________ From: Miroslav Lichvar <[email protected]> Sent: Thursday, January 7, 2021 10:11 AM To: [email protected] <[email protected]> Subject: Re: [chrony-users] Let chrony prefer gps source but allow online sources On Wed, Jan 06, 2021 at 01:48:00PM +0000, Ferry Schoenmakers wrote: > While restarting the machine with a gps fix lets chrony sync nicely with gps, > it doesn't do so when it synced with online sources first. Chrony never > 'switches' to gps, although it is set as preferred. Moreover, it seems that > it doesn't even receive measurement from gps? In your config there is no makestep directive. Is there a large initial offset in the online-sources-first test? There might be an issue with gpsd (I'm assuming you are using gpsd) that it stops providing measurements when the clock is being adjusted. IIRC that was the case at least with some old versions. I'd suggest to enable the gpsd debug output and see if there is any difference between the two tests. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
