On Thu, Feb 13, 2025 at 10:56:10PM +0100, Luis Chamberlain wrote: > On Sat, Feb 08, 2025 at 07:35:03PM +0100, Vincent Blut wrote: > > The next chrony revision will introduce some changes to the chrony.service > > file. Among them, the 'After=network.target' line will be dropped which > > I think might help fix this timing issue by letting chronyd start a bit > > earlier.
It might help statistically (at least on some systems) but I'd prefer a solution that prevents the race altogether. For now I've simply appended "|| true" to the "chronyc onoffline" invocation. If chronyd updates the connectivity at least once after it becomes ready to accept commands from chronyc there should be no problem. > > In the meantime, could you please check wether my assumptions is correct by > > modifying chrony.service with the aforementioned line removed. Not so easily. The problem is intermittent and the systems I've seen it on so far are servers which I can't just reboot at will. Luis may have (or have had?) a more suitable environment. I can try that change on my test VMs to check for regressions, but the timings there are not representative of physical servers. > > Luis, I suspect this issue has the same root cause as the one you > > reported in #1011533.ยน It would be nice to know if it can be reproduced > > using the 'kdevops reboot-limit' test with the chrony.service file > > modified as described above. > > + kdevops list > > Jeesh, I guess better late than never. That bug report was from 2022. > By now we've moved on from vagrant to guestfs and what would make > testing on debian even easier is for debian to just get proper debian > testing guestfs images out. > > Can you help us with that? > > Luis
