rwp | To have ntpd set the time set NTPD_OPTS='-g' in /etc/default/ntpsec as ntpd has replaced ntpdate about 20 years ago. | 00:26 |
---|---|---|
rwp | The -g will tell ntpd to jumpset the time at boot time. At boot time is the only race free and therefore trouble free time to jump the clock. But of course "service ntpsec restart" will act like boot time and jump set the time then. It's okay. | 00:26 |
gnarface | i've heard that ntpdate has been deprecated, but as of current stable it's still present in the repos and still a perfectly viable way to do a one-time sync of your system clock without needing to run a persistent daemon | 00:27 |
rwp | It's that "one-time sync" that I disagree with. | 00:31 |
rwp | If one is like my elderly friend who turns on her laptop once a week to check email whether she needs it or not, runs the machine for about 10 minutes, then powers it off until next week, then setting the clock at boot is okay. | 00:31 |
rwp | But if one is going to run a machine like my desktop which is on 24x7 then I want to run ntpd (or chrony for that side of the family) and have the clock always be in sync. | 00:32 |
rwp | At the point that we have installed the ntpsec package (or chrony) then it's a full stop shop with everything needed to do things absolutely correct. | 00:33 |
buZz | hmhm, its just a simple method for a onetime thing | 00:33 |
buZz | and likely ancient, arent we all | 00:34 |
buZz | sometimes i feel another word for deprecated , is 'done' :D | 00:34 |
rwp | I think ntpsec package should default to -g. Because what often happens is that things will work great! Things will work great for months, years. But then one day the clock will be power up and be more than the threshold off from correct and ntp will go, hold-up hold up somethings wrong here, and not jump set the time without -g telling it to do it. And then things are stuck in the broken state. Which frustrates people. | 00:35 |
buZz | when time is srsly wrong you get weird ssl errors too | 00:35 |
buZz | nonfunctioning crypto, totp, etc | 00:36 |
rwp | Sometimes the clock being incorrect is due to the clock battery failing with age. Which means replacing the CR2032 will get things back on track again. But if they are plugged into the internet with network time available it can just set it from the network. Like on a Raspbery Pi which does not have a battery clock. | 00:36 |
rwp | Right! Now that everything is https everywhere the clock has become a required to be correct feature. | 00:37 |
onefang | "buZz: when time is srsly wrong you get weird ssl errors too" Hmmm, might be why I'm getting wierd SSL errors. Only on apt-panopicon when it calls curl, and only when I run it on my desktop at my new home. It randomly gives me "The certificate is invalid." errors. I only just got unlimited HFC connected, was working fine at the last house where I had HFC, so I only just started poking at it. Everything else works fine, including multiple | 01:07 |
onefang | web browsers, with HTTPS everywhere extensions. | 01:07 |
buZz | and, is your time accurately set? | 01:07 |
onefang | But it's the beginning of a looong weekend here, so I'll poke at it more when that's over. No hurry. | 01:07 |
buZz | Fri Mar 29 01:08:08 CET 2024 | 01:08 |
onefang | chrony is running. | 01:08 |
onefang | Fri 29 Mar 2024 10:08:21 AEST | 01:08 |
buZz | 8 seconds off? | 01:08 |
onefang | Took me a few seconds to copy paste. | 01:09 |
buZz | i think we go to CEST tomorrow | 01:09 |
buZz | oh, ok | 01:09 |
rwp | My quick and dirty time check is "ssh remote.example.com date -R; date -R" and then the times are stacked and easy to compare. | 01:09 |
buZz | i do; /exec - -o date | 01:09 |
buZz | :P | 01:09 |
buZz | (in irssi) | 01:09 |
rwp | Being even an hour off won't cause certificates to be invalid, mostly. But if set to time 0 in 1970 then all certs will appear in the future and not yet valid. | 01:10 |
* onefang wonders if HexChat has a "run a shell command, output it to the channel". | 01:11 | |
gnarface | some stuff fails if you're more than 5 minutes off though... DNSSEC i think? | 01:11 |
gnarface | maybe other stuff | 01:12 |
rwp | DNSSEC? Maybe. I don't actually know the limits there. | 01:12 |
rwp | Raspberry Pis use a package (that I can never remember the name of) which sets the time to the time of shutdown, so that time is always increasing, and probably closer to reality than time 0 1970. | 01:12 |
gnarface | not sure, but i thought that's what happens if you just run "hwclock --systohc" before shutdown | 01:12 |
onefang | This is random failures. apt-panopticon does a whole bunch of downloads from all the package mirrors, including HTTPS, using curl. One will fail, but the very next one a fraction of a second later to the same mirror will work. | 01:13 |
onefang | Yep, you can tell your system to update the hardware clock at shutdown. Either that's done by default, or I've just been inheriting the config that does that for many years. | 01:14 |
onefang | Cool, HexChat has a Lua scripting plugin, didn't spot a shell one though. | 01:16 |
rwp | gnarface, The RPi does not have a battery and cannot keep the clock running when shutdown. Every power up is a cold start with time 0. | 01:20 |
onefang | I just tried rwp's ssh trick from my desktop to pkgmaster.devuan.org, the only difference was the timezone. | 01:27 |
onefang | Same with my own package mirror. | 01:28 |
onefang | Soooo, my time is OK. It's something else screwing with me. | 01:28 |
onefang | Which I shall leave until later to investigate, I got a loooong weekend to enjoy. B-) | 01:29 |
rwp | I should have added -u to have time in UTC! | 01:31 |
onefang | lol | 01:31 |
rwp | There is a saying sometimes see that I embrace. UTC or GTFO! | 01:31 |
rwp | I am not really that hardcore about it but I do lean that way. | 01:32 |
onefang | Well apt-panopticon displays times in GMT, but I do keep a UTC clock on my desktop | 01:32 |
onefang | date -u +"%N" is different between servers. B-) | 01:36 |
rwp | If your server it on the other side of the planet then relativistically it will be in a different time. Oh, sorry, that should be in OT! :-) | 01:38 |
onefang | Well that and it might take more than a few nanoseconds between the commands starting. | 01:41 |
gnarface | rwp: yea, i know that, but for some reason i thought that "hwclock --systohc" would still write to a file somewhere on the disk, so the next time it powers up the clock will start from that time instead of the epoch | 02:24 |
gnarface | i'm pretty sure it must, in fact, because my pine64 boards don't have a battery either and they don't come back up on reboot unless i do that first | 02:25 |
gnarface | maybe something else is causing that though, i dunno | 02:26 |
gnarface | i also ran into a weird situation once with some ibm raid card that would fail to boot unless you ran that during startup | 02:27 |
gnarface | i think it used to be in the stock debian shutdown scripts even, before the systemd people removed it | 02:28 |
gnarface | i think someone needs to help guckyy out with wifi | 02:28 |
onefang | Some RAID hardware has it's own internal battery backed up clock. | 02:41 |
rwp | Back in the day when I knew exactly what hwclock --systohc did I know it only updated the real time clock and did not save anything to files on disk as such. | 02:42 |
rwp | Agreed that the stock shutdown scripts would always update the RTC with the current time on the shutdown. It doesn't do that anymore? systemd. The dumbification of the world. | 02:45 |
mason | Hear him. | 03:46 |
Xenguy | guckyy your connection sucks | 04:30 |
Xenguy | too late | 04:30 |
onefang | The guckky connection is suckky. | 05:02 |
amarsh04 | I think that most of the pain of the 64 bit time upgrades are behind me now | 06:36 |
joerg | cmd: date >Fri Mar 29 09:15:49 CET 2024 | 09:15 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!