On Sat, Dec 30, 2023 at 12:19:12PM -0500, gene heskett wrote: > synopsis phase one: > I have installed ntpsec on this, my main machine,
What is its *name*? > Synopsis phase two: A QIDI X MAX-3 3d printer with a rockchip64 running > armbian 22.05 (buster) as the klipper, moonraker, and fluidd web interface > to control this printer. But its clock is wrong by about an hour 45 minutes > and short of trying to figure out settime, which might get it within 30 > seconds at best, I need to make nptsec behave like the long since deprecated > ntpdate command which could slam the current timedate into the clock > regardless, harmless if done in early boot but I'm told can be dangerous to > a running kernel. I'm confused by "phase two". Is ntpsec installed on the printer? Or is it ntp? Or chrony? Or systemd-timesyncd? Or none of the above? If all you want to do is set the clock manually, you can use the "date" command. Or you could install and use "ntpdate" or "rdate". But that's a band-aid. If you want to *keep* the clock in sync, then you need to get one of the NTP packages up and running, or if it's already running, figure out why it failed. Let's set one thing straight immediately: changing the clock isn't "dangerous to a kernel". The kernel really does not care about it at all. Other programs *might* care. Things like cron are pretty obvious -- if there's a scheduled job that's supposed to run at 2:00, but 2:00 never happens because you jumped over it, then the cron job might not run. Or if 2:00 happens twice, then the job may run twice. Desktop environments may also care. If the clock jumps forward, then a screen saver might kick in. Or other weird things might happen. Log files will look weird. Software development tools may also be affected, especially if a clock goes backward. Things like "make" compare modtimes on files to see which source files need to be recompiled. If the timestamps are messed up, then things may be recompiled unnecessarily, or worse, may *not* be recompiled when they should be. I have no idea what's running on your printer which might be sensitive to the system clock. That's for you to figure out. > root@mkspi:/usr/share# systemctl status ntpsec.service Which machine is "mkspi"? Is that the printer? Or is that the ntpsec server? > Active: active (running) since Sat 2023-12-30 09:26:32 EST; 43min ago If this is the printer (client) ... did you reboot it? Or did you try to restart ntpsec manually, at a time when the clock was already very wrong? I don't know the changes in ntpsec yet, but in the classic ntp package, it was only allowed to make a large clock adjustment *one* time, when first starting up during boot. Any subsequent restarts would only try to adjust the clock gradually. If you can't reboot the printer, then what you should do is stop the NTP program (ntpsec or whichever it is), set the clock by hand using "date" (or even "rdate" or "ntpdate"), then restart the NTP program. Ideally you would also ensure that any time-sensitive programs are stopped, and then restart them after the clock has been fixed. In practice, it might be better/easier just to reboot it. Of course, this will depend on the NTP program being able to reach your ntpsec server during boot, and set the clock at that moment. If THAT'S failing for some reason, then you'll need to figure out why.
