On 12/30/23 13:40, Greg Wooledge wrote:
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*?
fqdn:coyote.coyote.den but see my post from a few minutes back Greg, I
found it and its now working. Apparently THAT copy of ntpsec was built
to do nothing w/o 4 named peers in ntp.conf. So 3 of them are debian
pool members.
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?
ntpsec on the printer, there were traces of the other two but they are
stopped
and disabled now.
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.
The why clue was grudgingly disclosed by ntptrace which admitted to
using itself as a server, statum 16, which may as well have been on the
back side of the moon...
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.
The latter is expected. And as you say, harmless for a fwd jump . Now
its new years eve, and I need a box of self tapping 3/4" screws so I can
get back to work on a new table for this printer, One with storage
drawers for 16 kg of filament, but now I'm napping till Tuesday,
everybody has the weekend off.
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.
Absolutely. Thanks Greg & have a happier new year, the last 3 have
sucked about 10-34 torr.
root@mkspi:/usr/share# systemctl status ntpsec.service
Which machine is "mkspi"? Is that the printer? Or is that the ntpsec
server?
Thats the printer.
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?
Manually and with systemdctl, at least 40 times.
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.
Yup. Take care and stay warm and well, Greg. Even if it turns out to be
pebkamc (m meaning my chair) I appreciate it.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
