operating-system icon indicating copy to clipboard operation
operating-system copied to clipboard

time sync fragile, requires DNS to work by default

Open jackwasey opened this issue 3 years ago • 3 comments
trafficstars

Describe the issue you are experiencing

In haos in KVM, i repeatedly saw systemd-time-wait-sync.service systemd unit timing out. /etc/systemd/timesyncd.conf has a single, hardcoded primary NTP server time.cloudflare.com and NTP pool host names as the fallbacks. If DNS is not available, or fails to resolve these, then time is not synchronized, and unit is listed as failed.

A successful solution for me was to add IP addresses of NTP servers.

Recently systemd has network nameserver resolution specifically to avoid this problem, allowing NTP server name resolution independent of other name resolution. A simpler solution is to hard code multiple space-separated IP address of well known NTP servers, in addition to well-known, ideally non-proprietary, NTP servers.

What operating system image do you use?

ova (for Virtual Machines)

What version of Home Assistant Operating System is installed?

8.4

Did you upgrade the Operating System.

Yes

Steps to reproduce the issue

  1. block name resolution for haos host vm, e.g. drop UDP port 53 from the host.
  2. Start haos host vm (without any DNS services available)
  3. observe 90s timeout of the time wait sync unit in startup systemd logs ...

Anything in the Supervisor logs that might be useful for us?

No, just the timeout as described above

Anything in the Host logs that might be useful for us?

No, just the timeout as described above

System Health information

All good after I added IP addresses to timesyncd.conf

Additional information

No response

jackwasey avatar Aug 01 '22 15:08 jackwasey

A simpler solution is to hard code multiple space-separated IP address of well known NTP servers, in addition to well-known, ideally non-proprietary, NTP servers.

Afaik, most time servers only provide names, not IP addresses. Of course one can resolve it today and hardcode whatever it resolves today, but that might fail in the future since the NTP provider might change IP addresses.

Recently systemd has network nameserver resolution specifically to avoid this problem, allowing NTP server name resolution independent of other name resolution.

Do you happen to have a reference?

agners avatar Aug 04 '22 08:08 agners

Btw, a failed systemd-time-wait-sync.service should not prevent the system from functioning, especially if the RTC was correctly set. IMHO, it is fine for this service to fail, in case your DNS is (temporarily) down. Do you see any downsides?

agners avatar Aug 04 '22 08:08 agners

FYI Trying raspberry pi 4B installation. Same issue: 90s delay (the default timeout) as NTP sync fails. I accept this may be a local network quirk, but it is one that systemd-networkd may be configured to work around as described in timesyncd.conf, using FallbackNTP with at least some working public NTP server IP addresses.

jackwasey avatar Aug 20 '22 12:08 jackwasey

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Nov 18 '22 13:11 github-actions[bot]