On Mon, 13 May 2024, Feng Tang wrote:
[CAUTION: Non-UBC Email]
Hi Miroslav Lichvar,
On Mon, May 13, 2024 at 08:19:07AM +0200, Miroslav Lichvar wrote:
On Mon, May 13, 2024 at 09:02:31AM +0800, Feng Tang wrote:
So my thought is, since user already chose to trust 'chrony', and
when chrony has more realiable NTP time source, 'chrony' can help to
correct the 'wrong date' set by user with the right time, practically
'rejecting' the huge time jump set by users.
chronyd is trying to correct the clock, but a typical default
configuration provided with distro packages allows steps only on
start, so the ~10% slew can take very long time.
Yes, exactly. In the above case, we saw the system time was compensated
very slowly.
It slews at 1 sec per 10 sec. if the clock is way out.
The user would need to allow steps at any time. See this answer in
the FAQ:
https://chrony-project.org/faq.html#_is_chronyd_allowed_to_step_the_system_clock
This works great in my test and the issue can't be reproduced. Many
thanks for the hint!
BUT you have to tell you users NOT to change the clock on their own. DO NOT
USE date to change the clock. If your users are going to do idiotic things
there is nothing you can do to correct all of their idiocies. Do not do it "as
a test" It is not a test. Nothing will ever make the clock suddeny jump time.
NOt allowing your clocks to jump may well produce worse things that you are
complaining of now.
- Feng
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
