On Wed, Jan 31, 2024 at 12:56:37PM -0500, gene heskett wrote: [...] > # Stop bad estimates upsetting machine clock. > maxupdateskew 100000.0 > initstepslew 30 192.168.71.3 > # This directive enables kernel synchronisation (every 11 minutes) of the > # real-time clock. Note that it can’t be used along with the 'rtcfile' > directive. > rtcsync > > # Step the system clock instead of slewing it if the adjustment is larger > than > # one second, but only in the first three clock updates. > makestep 1 3000
I've never used chrony, so all I know about it is what I've gleaned from skimming the chrony.conf page, from Google search results, and from things that people have said here. With that in mind, I don't know what happens if you've got both initstepslew *and* makestep in the same conf file. I would imagine you only want one of them. > Dec 30 03:15:32 bpi51e5p chronyd[1936]: Using right/UTC timezone to obtain > leap second data > Dec 30 03:15:32 bpi51e5p chronyd[1936]: Loaded seccomp filter (level 1) > Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3 > Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew > Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3 That IP address clearly came from your initstepslew line. Is there an NTP service running on that host? If so, is it synchronized? And does it permit client requests (from bpi51e5p)? > Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936 does > not exist or is a zombie. > Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result > 'protocol'. > Dec 30 03:15:44 bpi51e5p systemd[1]: Failed to start chrony, an NTP > client/server. This appears to be important. It's failing to start, which means it's not setting the clock, or doing anything else. You'll need to figure out why it's not starting. Perhaps it's *just* the fact that it can't contact an NTP service at 192.168.71.3. Or maybe there's more to the story. I don't know.
