Re: [chrony-users] Resume from suspend and default makestep configuration

[FUSTE Emmanuel <emmanuel.fuste@xxxxxxxxxxxxxxx>]

Le 19/05/2020 à 17:54, Pali Rohár a écrit :
> 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.
> 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
Systemd know that you are resuming from suspend.
> jump occurred and only after it synchronize time via NTP. And until NTP
Wrong. Chrony does not need to sync via NTP to see that the system clock 
jumped.

> daemon tell (somehow) hat this jumps occurred, systemd cannot know that
> during hibernation RTC clock was modified.
That should not happen in normal case.
>
> 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
RTC should be the trusted source in this case so init system, knowing 
that you are resuming from should notify ntp daemon that all is ok
(launch "chronyc reset" in the devel version).

After that, on a "sane" computer, you could even now drop the makestep 
parameter for the paranoids like me.