I am reminded, again, how much I utterly dislike timesyncd, and how bad it is at the one freaking job it's supposed to do
goes and installs chrony to have time stop being stupid
=> More informations about this toot | More toots from warthog9@social.afront.org
What does it do wrong?
=> More informations about this toot | More toots from josh@joshtriplett.org
@josh as observed, and noting i haven't dug into it's code, it's no better than ntpdate and hope after that. I've seen it be running and a live system be an hours off after srarting in sync. VMs will suspend and never catch up after a resume. It's fine for anything short lived, and ephemeral, but anything longer than a few hours it's hard to trust it.
Tonight's fun were VMs that didn't catch up causing ssl issues, and a couple of debian 12 systems being behind by 4-6 hours over an uptime of ~100 days with timesyncd claiming it's doing the right thing.
=> More informations about this toot | More toots from warthog9@social.afront.org
@josh tl;dr: it doesn't actually keep the clock in sync
=> More informations about this toot | More toots from warthog9@social.afront.org
@warthog9 @josh Is there a problem I'm not aware of with using ntpd?
=> More informations about this toot | More toots from mansr@society.oftrolls.com
@mansr @josh ntpd is great, just old. Cheony cuts a bunch of hard to deal with protocols no one uses and is more prone to jump or large skew vs slew so it's slightly nicer on mobils and machines that are up down a lot. I'd put xheony on par with ntpd with minor differences when one might be slightly better in a deployment
=> More informations about this toot | More toots from warthog9@social.afront.org
@warthog9 @mansr @josh I use OpenNTPD everywhere. Cleaned up and stripped down with added security features, provided by the same project that gives us OpenSSH. #OpenBSD
=> More informations about this toot | More toots from Tubsta@soc.feditime.com
@Tubsta @josh @mansr not a bad option, I prefer chrony but ntpd and it's derivatives arent a bad option in my opinion
=> More informations about this toot | More toots from warthog9@social.afront.org
Huh. Strange. I've never seen that on any of my systems running it, but then, I don't think I have any systems that are that long-running to get out of sync by hours. Is there an issue upstream?
=> More informations about this toot | More toots from josh@joshtriplett.org
@warthog9 hmm it's been working well enough in Ubuntu to be used as a default. Like Josh I'd like to know the finer details of what's not working.
(There's an open question of switching to chrony by default on Ubuntu server because of NTS support, but that's likely not the problem you're running into.)
=> More informations about this toot | More toots from vorlon@mastodon.social
@vorlon the extent I've debugged is "why is this system clock so off? Ohhhh timesyncd is running, install chrony" at which point the clock sync works exactly the way you'd expect. This is a fairly common refrain, enough that in my ansible playbooks there's a section to rip it out because it happens so often.
Why? No idea why timesyncd is borked, but syncing time is a genuinely complex thing to do right and I can only fathom that timesyncd took an "obvious" way to do it that missed half the corner cases or problems and I keep being out of aync as a reault. Seen it on ARM systems, x86-64, VMs, etc. I see it on occasion on Ubuntu boxes too so it's not a Debian being old vs Ubuntu having newer issue either.
Personally: I'd vote chrony.
=> More informations about this toot | More toots from warthog9@social.afront.org This content has been proxied by September (ba2dc).Proxy Information
text/gemini