Delay Supervisor start until time has been sychronized#1360
Merged
agners merged 3 commits intohome-assistant:devfrom May 12, 2021
Merged
Delay Supervisor start until time has been sychronized#1360agners merged 3 commits intohome-assistant:devfrom
agners merged 3 commits intohome-assistant:devfrom
Conversation
Enable the systemd-time-wait-sync.service by default. This allows to use the time-sync.target which allows to make sure services only get started once the time is synchronized.
Use the time-sync.target to make sure that the Supervisor gets stsarted after the time has been synchronized.
Don't delay startup forever in case time synchronization doesn't work. This allows to boot the system even without Internet connection.
pvizeli
approved these changes
May 12, 2021
7 tasks
agners
added a commit
to agners/operating-system
that referenced
this pull request
Aug 17, 2022
With commit 2d3119e ("Delay Supervisor start until time has been sychronized (home-assistant#1360)") systemd-time-wait-sync.service got enabled, which waits until systemd-timesyncd synchronizes time with a NTP server. By default systemd-timesyncd.service and systemd-time-wait-sync.service are pulled in by sysinit.target. This starts the services before full network connectivity is established. The first sychronization fails and systemd-timesyncd only retries after a ratelimit mechanism times out. This causes a dealy of 30s during startup. While systemd-timesyncd has a mechanism to (re)try time synchronization when network becomes online, it seems that those only work properly when systemd-networkd is used, see also systemd/systemd#24298. Simply reordering systemd-timesyncd.service after network-online.target does not work as it causes circular dependencies (NetworkManager itself depends ultimately on the sysinit.target). With this change, the services are only pulled in by time-sync.target. That allows to order the service after network-online.target. With that the first synchronization succeeds. This mechanism also works when a NTP server is provided through DHCP. In that case, a the systemd-timesyncd service is started by the dispatch script /usr/lib/NetworkManager/dispatcher.d/10-ntp before the systemd even considers starting the service. Tests show that the default fallback NTP is not contacted, only the DHCP provided service.
agners
added a commit
that referenced
this pull request
Aug 17, 2022
With commit 2d3119e ("Delay Supervisor start until time has been sychronized (#1360)") systemd-time-wait-sync.service got enabled, which waits until systemd-timesyncd synchronizes time with a NTP server. By default systemd-timesyncd.service and systemd-time-wait-sync.service are pulled in by sysinit.target. This starts the services before full network connectivity is established. The first sychronization fails and systemd-timesyncd only retries after a ratelimit mechanism times out. This causes a dealy of 30s during startup. While systemd-timesyncd has a mechanism to (re)try time synchronization when network becomes online, it seems that those only work properly when systemd-networkd is used, see also systemd/systemd#24298. Simply reordering systemd-timesyncd.service after network-online.target does not work as it causes circular dependencies (NetworkManager itself depends ultimately on the sysinit.target). With this change, the services are only pulled in by time-sync.target. That allows to order the service after network-online.target. With that the first synchronization succeeds. This mechanism also works when a NTP server is provided through DHCP. In that case, a the systemd-timesyncd service is started by the dispatch script /usr/lib/NetworkManager/dispatcher.d/10-ntp before the systemd even considers starting the service. Tests show that the default fallback NTP is not contacted, only the DHCP provided service.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On first boot, the RTC of many embedded boards can be off. Currently the Supervisor gets started immediately, which then leads to conection failures when trying to connect to https targets since the certificate appears to be invalid (typically the validity is in the future from the boards perspective).
Make sure to delay Supervisor start until time has been synchronized. Wait a maximum of 90s, and continue boot in case synchronization isn't possible (no Internet connectivity).