| Re: [chrony-users] Resume from suspend and default makestep configuration |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Tue, 19 May 2020, Pali Rohár wrote:
On Tuesday 19 May 2020 17:36:15 Miroslav Lichvar wrote:
On Tue, May 19, 2020 at 03:11:42PM +0200, Pali Rohár wrote:
Also when resuming from hibernation you may have been completely powered
off and also memory of system may have been modified. Plus multiOS
scenario may have applied, e.g. ordinary user just "booted" windows and
then turned it off and resumed linux from hibernation. I guess we would
agree that ordinary user does not use any virtualisation as you
described below.
I don't think that's a common practice. If you suspend an OS and boot
another, all kind of things can break, like corrupted swaps, etc. If
you know what you are doing, fine, but don't be surprised when things
break.
I know that lot of people are doing it. They are not developers,
sysadmins or people who watch mailing list, ... just normal users.
Sure they are.
So from my observation, this is common. Maybe it is less common by
developers who know what can happen and break, but not uncommon by
ordinary non-power users.
When hibernating windows it puts special signature on NTFS filesystems
and Linux's ntfs-fuse refuse to mount in R/W mode such "hibernated" NTFS
filesystem. So there is no corruption of hibernated windows state.
Windows does not support accessing ext4, btrfs or linux swap so there is
corruption of linux fs/swap from windows.
When chronyd is running, it assumes it has full control over the
system clock. When you suspend and resume the OS or machine, the
system clock is reset to the RTC. chronyd can see there was a forward
jump, but it doesn't know what happened. systemd should know that and
there could be a unit to call the chronyc reset and makestep commands
if a significant offset is expected.
But systemd cannot know that. It is chronyd who see that significant
Sure it can. systemd knows that the system was hibernated. It did the
hibernating. It does not need to look at the clock to know it was hibernated.
So, systemd can stop and restart chronyd.
Hibernation always causes system time problems. So, it is systemd that can
ammeliorate the time problems caused by hibernation. Chrony does not know that
the system was hibernated, it just sees a weird jump in time which it has not
idea why it occured.
jump occurred and only after it synchronize time via NTP. And until NTP
daemon tell (somehow) hat this jumps occurred, systemd cannot know that
during hibernation RTC clock was modified.
systemd knows it was hibernated. It did it. So systemd has the responsibility
of cleaning up after itself, which could include stopping and restarting
chrony.
This looks like a chicken and egg problem. systemd (or any other init /
service system) does not know correct time after resuming system from
suspend/hibernate, so it cannot check if RTC jump occurred. chronyd is
But it know hibernation occured.
waiting for some reset command from systemd to fix insecure system
clock but systemd does not know that clock is incorrect... So the result
it that system clock is incorrectly set, user has incorrect time.
Sure it does. It know it hibernated and thus knows that time problems will
have occured.