Re: is there an ntpsec wizard here?
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
Re: is there an ntpsec wizard here?
On 12/30/23 12:19, gene heskett wrote: synopsis phase one: I have installed ntpsec on this, my main machine, and have successfully switched 5 of my other networked machines to use this statum 2 server instead of pestering the debian server pool. However, I have it restricted to replying only to members of my private network. 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. Now I need to get far more familiar with systemd than I am. For those of you using ntpsec, and it is generating the proper logs in /var/log/ntpsec, I need to see how you have accomplished this in your /etc/ntpsec/ntp.conf, enabling the logging of everything it does, I'm getting nothing here in that properly configured path, and /lib/ntpsec/ntp,drift is stuck at 00.0. While: root@mkspi:/usr/share# systemctl status ntpsec.service ● ntpsec.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntpsec.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2023-12-30 09:26:32 EST; 43min ago Docs: man:ntpd(8) Process: 15642 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS) Main PID: 15645 (ntpd) Tasks: 1 (limit: 998) Memory: 9.0M CGroup: /system.slice/ntpsec.service └─15645 /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec Dec 30 10:00:41 mkspi ntpd[15645]: DNS: Pool skipping: 192.168.71.3 Dec 30 10:00:41 mkspi ntpd[15645]: DNS: dns_take_status: coyote.coyote.den=>good, 8 Dec 30 10:04:57 mkspi ntpd[15645]: DNS: dns_probe: coyote.coyote.den, cast_flags:8, flags:101 Dec 30 10:04:57 mkspi ntpd[15645]: DNS: dns_check: processing coyote.coyote.den, 8, 101 Dec 30 10:04:57 mkspi ntpd[15645]: DNS: Pool skipping: 192.168.71.3 Dec 30 10:04:57 mkspi ntpd[15645]: DNS: dns_take_status: coyote.coyote.den=>good, 8 Dec 30 10:09:13 mkspi ntpd[15645]: DNS: dns_probe: coyote.coyote.den, cast_flags:8, flags:101 Dec 30 10:09:13 mkspi ntpd[15645]: DNS: dns_check: processing coyote.coyote.den, 8, 101 Dec 30 10:09:13 mkspi ntpd[15645]: DNS: Pool skipping: 192.168.71.3 Dec 30 10:09:13 mkspi ntpd[15645]: DNS: dns_take_status: coyote.coyote.den=>good, 8 root@mkspi:/usr/share# Which to me looks like it ought to be working but is obviously not working. Capturing my ntpsec server traffic on port 123 shows mmkspi is accessing the server and the server is responding at several minute intervals: 11:48:15.267912 IP mkspi.coyote.den.ntp > coyote.coyote.den.ntp: NTPv4, Client, length 48 11:49:21.274706 IP coyote.coyote.den.ntp > mkspi.coyote.den.ntp: NTPv4, Server, length 48 11:50:26.267614 IP mkspi.coyote.den.ntp > coyote.coyote.den.ntp: NTPv4, Client, length 48 11:50:26.267681 IP coyote.coyote.den.ntp > mkspi.coyote.den.ntp: NTPv4, Server, length 48 But the date 45 seconds later on mkspi is: Sat 30 Dec 2023 10:24:10 AM EST I have used systemctl to stop and disable both timesyncd.service and chrony.service since neither seems to want to access my ntpsec server. Acc the docs I've read, all 3 of these utilities s/b able to do the job. And I'm lost w/o any info to debug this, no log files at all. Those log file locations are NOT on my raid that is being so d_d cantankerous. My thanks to anyone who can help. Call in the St. Bernards, tap the cask, and have a happy new year, I found it, it jumped over 6000 seconds and the date output is now correct. And it did not crash the printer. I'm a happy camper. Cheers, Gene Heskett. 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
Re: is there an ntpsec wizard here?
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.
