time-sync.target is improperly reached with chronyd #1776
Labels
os/time
TIme synchronization overhaul
Comments
xginn8
changed the title
time-sync.target is improperly reached with chronyd
|
@xginn8 in an ideal world, we could wait for real time sync before reaching Time does jump in the OS. See https://github.com/balena-os/meta-balena#time-in-the-os I don't think the solution to #1779 is in time-sync but open to ideas and suggestions |
|
@ZubairLK, imho we should order units that strictly require time synchronization after |
markcorbinuk
added a commit
that referenced
this issue
Aug 18, 2020
Improve the reliability and robustness of time synchronisation during boot. A new time-set.target has been added (as per systemd versions since v242). The timeinit-rtc and timeinit-timestamp services have been added to the time-set.target. Chrony is now part of the time-sync.target and has a dependency on the time-set.target. New services have been added to the time-sync.target to ensure that system time is synchronised with a remote source before the time-sync.target is reached. The timesync-remote service is a blocking service that will only terminate if: a) NTP synchronisation has been achieved (via chrony), or b) time is successfully updated using ntpdate, or c) time is successfully updated from an HTTPS header (using curl). The timesync-https service is a background service that will periodically attempt to update the system time from an HTTPS header. The service will terminate if NTP synchronisation has been achieved (via chrony). This service provides a time synchronisation backup in cases where access to NTP port 123 is blocked. The openvpn service now pulls in the time-sync.target and will only start after initial time synchronisation has completed as described above. Change-type: minor Connects-to: #1852 #1776 #1337 Signed-off-by: Mark Corbin <[email protected]>
markcorbinuk
added a commit
that referenced
this issue
Sep 30, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the system time providing that it is in advance of the current system time. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. The service provides time synchronisation for devices where NTP is blocked. For devices where NTP is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
markcorbinuk
added a commit
that referenced
this issue
Oct 11, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the system time providing that it is in advance of the current system time. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. The service provides time synchronisation for devices where NTP is blocked. For devices where NTP is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
markcorbinuk
added a commit
that referenced
this issue
Oct 26, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the system time providing that it is in advance of the current system time. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. The service provides time synchronisation for devices where NTP is blocked. For devices where NTP is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
markcorbinuk
added a commit
that referenced
this issue
Oct 27, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
6 tasks
6 tasks
ghost
pushed a commit
that referenced
this issue
Oct 27, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 3, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 5, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
markcorbinuk
added a commit
that referenced
this issue
Nov 5, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 12, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 15, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 16, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 16, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 17, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 21, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 22, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Nov 26, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
pushed a commit
that referenced
this issue
Dec 1, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
markcorbinuk
added a commit
that referenced
this issue
Dec 1, 2021
Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used *must* return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal. The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC. The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received. This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete. Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds. Change-type: minor Connects-to: #1337 #1776 #2044 #2139 Signed-off-by: Mark Corbin <[email protected]>
ghost
closed this as This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
chronydis aType=simple, and therefore considered active as soon as the process forks. Since it is ordered beforetime-sync.target, time is assumed to be synchronized once thechronydprocess is forked. Follow-on processes that actually require time to be fully synchronized are started immediately, whilechronydis still forcing clock changes.Specifically, this results in a connection cycle (
ping-restart) foropenvpn, since the clock changes andopenvpnthinks it hasn't received a ping in a time that's over the threshold. cc @wrboyce @alexggThe text was updated successfully, but these errors were encountered: