Is `systemd-timesyncd` suitable for use on servers?

Posted by lightnb11@reddit | linuxadmin | View on Reddit | 28 comments

It looks like systemd-timesyncd comes with Debian 12 now, and when we run provisioning against new servers to install ntp, systemd-timesyncd gets removed.

Is systemd-timesyncd suitable for use on servers (that aren't time servers for other services), or should we use ntp on all servers?

[-]

juggernaut911@reddit

Personally I try to lean on systemd native functions in lieu of extra packages/daemons. I use systemd-timesyncd for my ntp usage (instead of ntp) and systemd-networkd acts as my mdns responder on a particular interface (instead of avahi) (see MulticastDNS setting here)

[-]

rconti@reddit

Man I just had the misfortune of learning timesyncd today (and stumbled across this thread in so doing), and I recommend against it based on naming alone.

The service being named systemd-timesyncd and the binary being called timedatectl and the arguments being inconsistently named show-timesync and timesync-status is just insane. Who comes up with this stuff?

[-]

juggernaut911@reddit

The man page is always a good place to start! https://www.man7.org/linux/man-pages/man8/systemd-timesyncd.8.html

[-]

broknbottle@reddit

No it’s absolute junk and not suitable for anything. Use Chrony

[-]

french_violist@reddit

What’s wrong with ntpd?

[-]

shemanese@reddit

Deprecated.

https://www.debian.org/News/2023/20230610

"The ntp package has been replaced with the ntpsec package, with the default system clock service now being systemd-timesyncd; there is also support for chrony and openntpd"

So, the choices are ntpsec, chrony, openntpd, or systemd-timesyncd.

[-]

french_violist@reddit

Yes, you’re right. Let me rephrase, what’s wrong with openntpd? I see chrony recommended everywhere, yet openntpd does the job just fine too.

[-]

DigitalDefenestrator@reddit

Chrony seems to be more aggressive and persistent in practice in terms of disciplining the clock. It's written with modern hardware in mind, so tighter clock in return for higher overhead that's still negligible on modern hardware but might have mattered 20 years ago.

[-]

NoAssociation7938@reddit

Nothing wrong with it, it's basically got identical features to chrony

[-]

skc5@reddit

Except for NTS, drift tracking, defining multiple sources for accuracy and redundancy, or accuracy better than 100-1000ms that SNTP gets with timesyncd.

[-]

DigitalDefenestrator@reddit

It depends on how much precision you need on your clock sync. Timesyncd will get it on the order of 100ms to 1s, with some slop if the hardware clock drifts quickly. Plenty good enough for "what time is it?", iffy on log correlation, and not good enough for systems like Cassandra that depend on it for consistency.

NTPD gets you within about 10ms, with stricter discipline of drift.

Chrony gets you closer to 1ms, which is good enough for almost everything.

[-]

spaetzelspiff@reddit

And then ptpd for the tens of micros..

[-]

NoAssociation7938@reddit

I would recommend chrony instead

[-]

seidler2547@reddit

I think I would only use chrony if I wanted to provide a local time server. Just for syncing systemd-timesyncd is totally enough.

[-]

NoAssociation7938@reddit

I would say thats try if you don't need secure time or a high level of accuracy

[-]

skc5@reddit

Not sure why you’re being downvoted, you’re right. Unless you need more accuracy, timesyncd is fine.

I still prefer chrony but I’m a time nerd that likes accuracy.

[-]

ImpostureTechAdmin@reddit

Stuff like this is a lot more helpful if you mention why

[-]

ChrisTX4@reddit

I'd say there are two key advantages of Chrony over systemd-timesyncd:

systemd-timesyncd is a really simplistic implementation of NTP, in fact they use a variant called Simple NTP or SNTP. This variant is inherently less accurate already. Timesyncd also does not perform any clock discipline, there's no drift tracking or anything of that sort, further decreasing accuracy. If you strictly need that accuracy for a given workload is another question, but there's no downside of having it.

Additionally, Chrony can make use of Network Time Security (NTS), which is basically "time over TLS". This protects against possible attacks to manipulate a machine's clock. I'd say those are unusual

Now, Timesyncd might be alright for a given workload, but as there's no downside for running Chrony instead, just upsides, and you have to configure NTP for servers usually anyways, I don't really see a reason why you would.

(As for Chrony vs NTP: NTP is a reference implementation and as such generally not really optimised. In terms of accuracy you'll normally see Chrony being more accurate than NTP, which in turn is more accurate than Timesyncd, due to using NTP proper and not SNTP)

[-]

chronic414de@reddit

I read in the Proxmox patchnotes that they switched from systemd-timesyncd to chrony because systemd-timesyncd only synchronizes the time when the system gets booted.

[-]

Genesis2001@reddit

I've actually had to enable it on some of our servers due to time desyncs for MFA tokens on some websites we host, and it works fine.

[-]

autogyrophilia@reddit

God how could you roll without ntp before?

[-]

Genesis2001@reddit

Luck mostly, I guess. But it's something I'm updating our ansible playbooks to setup automatically now.

[-]

kevdogger@reddit

Idk. I keep flip flopping back and forth between systemd-timesyncd and chrony. I haven't kept stats. Pfsense runs a chrony server which is local ntp server I'm using as ntp source

[-]

exekewtable@reddit

I have had drift on timesyncd and ntpd, where chrony has none, on virtual machines.

[-]

michaelpaoli@reddit

systemd-timesyncd

It's essentially a time sync client app. So, if that's all you need, that may suffice. But if you need an NTP server, systemd-timesyncd isn't your answer.

[-]