Check if system is synchronized on NTP #16
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.
Hello,
You may not want to merge this since we ended up rewriting a lot of things and it may be growing out of scope of what alarm-fake-hwclock is meant to do. Anyways, here it is for reference, at least.
The issue we have encountered:
If, for some reason, the date of the reference file ends up being set some time in the future, alarm-fake-hwclock will keep restoring that date every time it is run, even if we have a better date set from NTP. This leads to the date being set in the future every 15 minutes as alarm-fake-hwclock runs, and then set back to the right time by NTP, but the correct date is never stored in the reference file.
To fix this, we decided to have alarm-fake-hwclock query the NTP client and check if the clock is currently synchronized. In that case, it will assume that clock is correct, and never use the time from the reference file. Otherwise (including if there is no NTP client running), things work as usual.