1

On an Archlinux host, I noticed that command timedatectl status returned correct result for times (local and UTC) but also mentioned that the NTP service was inactive.

That struck me as odd because ntpd.service is enabled and active on that machine, even though systemd-timesynd.service is present but not enabled.

On https://unix.stackexchange.com/a/542959/72707 I saw that provided the systemd-timesync.service is available, doing:

# timedatectl set-ntp true

is enough to show an active NTP service in the output of timedatectl status.

I also saw that it automatically enabled and activated systemd-timesync.service.

Hence my question:
Do I need the ntpd.service at all ? Is there a differentiated need for both systemd-timesync.service and ntpd.service?

αғsнιη
  • 40,939
  • 15
  • 71
  • 114
Cbhihe
  • 2,549
  • 2
  • 21
  • 30

1 Answers1

2

Quoting from @don_crissti's comment to directly answer OP's query:

You don't need the ntpd.service if you're using the timesyncd one. I use the latter on several desktops that don't even have the ntp package installed. Read the arch wiki entry about it here: wiki.archlinux.org/title/Systemd-timesyncd

Aside from that quote, with modern versions of timedatectl (and corresponding systemd-timedated), there is a list of time synchronization services in /usr/lib/systemd/ntp-units.d/*.list files. As usual, you can use /usr/local/lib/systemd/ntp-units.d/*.list files to make timedatectl aware of locally-administered (= not installed from packages) time synchronization services, or /etc/systemd/ntp-units.d/*.list for administrative overrides to existing time sync service lists.

Setting the environment variable SYSTEMD_TIMEDATED_NTP_SERVICES for the systemd-timedated service is another way you can override the list of time sync services.

When you do a timedatectl set-ntp true, systemd-timedated will look at its list of time synchronization service names, and will start the first listed service that is actually available.

To make your timedatectl aware of ntpd.service, you could do something like this:

echo "ntpd.service" | sudo tee /etc/systemd/ntp-units.d/10-ntpd.list

systemd-timesyncd was originally developed as a minimalistic service to just periodically fetch time from a NTP server, effectively a SNTP client. It seems to be developing into a more complete NTP client, but I'm unsure as to how it compares to e.g. classic ntpd at this time.

A more full-featured NTP synchronization service like chronyd or ntpd will also constantly measure packet round-trip times between the local system and the NTP time sources, compensate for it, and also measure and compensate for systematic errors of the local system clock.

systemd-timesyncd was originally meant for embedded systems and other use cases where it's nice to have "human-scale" correct time, but not necessary to achieve very high accuracy.

With a well-configured chronyd or ntpd and a good set of nearby NTP servers, you can get your systems synchronized to within a millisecond or better.

If you need your systems synchronized down to the microsecond or even better, you can get with NTP with careful tweaking, but it might be better to use PTP in that case.

Note that the development of the classic ntpd has stalled in the recent year or two, and it has some known security issues. Newer implementations like chronyd and NTPsec might be more secure.

Cbhihe
  • 2,549
  • 2
  • 21
  • 30
telcoM
  • 87,318
  • 3
  • 112
  • 232
  • +1: Truly informative contribution although i had read on the dfference between `ntp` and `ntpd` already ans well as on the comparatively lightweight character of `systemd-timesyncd`. I do not accept your answer because it does not apply to OP. If with @don_crissti's approval you include their comment in your answer, i will make sure i accept it. Thank you. – Cbhihe Jan 12 '23 at 17:04
  • @don_crissti: in the absence of an answer by telcoM, I integrated your answer in his/hers and accepted the result as the official answer. Thank you both. – Cbhihe Jan 17 '23 at 18:20