4

the ntp string isn't found in syslog. It's definitely not running. But when it has internet access, it has the right time. What's the mechanism?

This is on Raspbian Stretch minimal install.

7

In Stretch the synchronisation is done using a systemd service (systemd-timesyncd.service) and a new program (systemd-timesyncd)

For time status information use timedatectl For status information about the timesync service use

sudo systemctl status systemd-timesyncd

You will probably see the time has been updated at some point

More information is available with

man systemd-timesyncd.service
  • I see. This is a different question, but How could I force the time sync to happen in a script? – Steven Lu Aug 9 '18 at 22:13
  • @Dirk: Good explanation - it's a question rattling around in the back of my mind for a while. But a closely related question (actually part of the OP's "subject" question) is this: How does RPi determine timezone? Is this done during installation? – Seamus Aug 9 '18 at 22:27
  • @StevenLu: Good question - I was wondering the same thing. And your question was asked here, but never answered - so when you find the answer, please "plug it in" there. As an incentive, you were aware that you get a check for $1,000,000 once you get to 1,000 points reputation, right? (ha ha - joking of course :) – Seamus Aug 9 '18 at 23:03
  • @StevenLu Sorry, I don't know. I think it has come up on the RPi forum, but I can't find any relevant posts ATM – Dirk Aug 9 '18 at 23:07
  • @Seamus The Raspbian images have the timezone preset to the UK. You would use the config utilities to change that (or do it manually of course). Latest Raspbian Desktop has the new setup utility that will ask for the timezone. It may do something automatically, but I would not notice because I'm in the UK timezone – Dirk Aug 9 '18 at 23:10
1

I'm posting an answer to augment @Dirk's answer, not to take exception. I believe @Dirk's answer is completely accurate, but it did pique my curiosity for details. I'm posting some of those details here as they may be relevant for some (including the OP).

As @Dirk mentioned, the ntp client was replaced with systemd-timesyncd beginning with the stretch distribution. It seems there were two motivations for this replacement:

  1. some felt that ntp was not an example of "good software"
  2. some felt that using a systemd-based time service was consistent with other changes being implemented in Linux

All well and good, yet according to the documentation, there were some tradeoffs made:

The systemd-timesyncd service specifically implements only SNTP. This minimalistic service will set the system clock for large offsets or slowly adjust it for smaller deltas. More complex use cases are not covered by systemd-timesyncd.

SNTP is the Simple Network Time Protocol defined by RFC2030, which says in part:

SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified.

A discussion of the diffs between NTP and SNTP can be found here, which quotes another passage from RFC-2030:

SNTP servers should operate only at the root (stratum 1) of the subnet and then only in configurations where no other source of synchronization other than a reliable radio or modem time service is available.

This should NOT be taken as a suggestion that the systemd-timesyncd timekeeping function in RPi is unsuitable. It is after all, a "hobbyist computer"... but then so were Macs and PCs when they first arrived. And so there may be "serious" applications for Raspberry Pis that demand NTP over SNTP, or there may be other applications wherein the user wants or needs the ability to, for example, exercise control of the timekeeping function with a program or script[1, 2]. In these cases, systemd-timesyncd may fall short.

If you fall into this category, and feel systemd-timesyncd doesn't meet your needs, you have at least three options:

  1. install ntp; the client used on RPi prior to the stretch release, and maintained by the Network Time Protocol project

  2. install openntpd; a client developed as part of the OpenBSD project

  3. install chrony; a project supported by TuxFamily

ArchLinux has documentation on ntp, openntpd and chrony that may help you decide which best suits your needs. You may also wish to review the docs for timedatectl available on ArchLinux before you make this change. All three packages are available for RPi, can be installed with the usual sudo apt-get install X incantations.

If you elect to install one of these NTP implementations, you could disable systemd-timesyncd as follows:

$ timedatectl set-ntp false

However: As my colleague @Ingo has pointed out, this is not necessary since systemd-timesyncd checks for the presence of other NTP daemons, and will adjust its behavior accordingly; see systemctl cat systemd-timesyncd.

  • There is no need to disable systemd-timesyncd. It will check if there is another NTP daemon installed. Check with `systemctl cat systemd-timesyncd´, bottom lines. – Ingo Aug 10 '18 at 10:02
  • @Ingo: Brilliant! I'm confused though... that command systemctl cat systemd-timesyncd is an odd one! It lists 48 lines & stops... I've not found any way to get the rest of the file, and man systemctl is silent on that topic. As an aside, it seems that systemctl is in "takeovertheworld" mode :) – Seamus Aug 10 '18 at 12:48
  • On my default Raspbian systemd-timesyncd has 52 lines including copyright disclaimer and with systemctl cat it is opened in a pager (less) so you should be able to easily scroll down. And yes, systemd has already taken over the world. Everything from "the old stuff" is only emulated by systemd, even fstab (man systemd.generator). – Ingo Aug 10 '18 at 13:11
  • Hmmm... the pager acts strangely for me. If I have a terminal window sized such that lines 1-48 is displayed in inverse video at the bottom of my screen, then most of the "usual" keys terminate it, and take me to command prompt. However, if I resize my terminal window, the paging behavior becomes "normal". But yes, systemd is pervasive now... not sure I like that just yet, but we'll see. – Seamus Aug 10 '18 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.