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

[Pali Rohár <pali.rohar@xxxxxxxxx>]

On Tuesday 19 May 2020 16:07:57 FUSTE Emmanuel wrote:
> 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.

Of course, systemd knows it. And similarly also other applications can
know it.

> > 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.

Ok, to be precise, chrony needs to sync via NTP to see that system clock
(during suspend / hibernate) jumped with correct delay. Also what may
happen is that clock does not jump, but it should. Also chronyd cannot
detect it until it do sync via NTP.

> > daemon tell (somehow) hat this jumps occurred, systemd cannot know that
> > during hibernation RTC clock was modified.
> That should not happen in normal case.

But it happens, this is reason why I started this email thread.

> > 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 

In previous emails I show that generally it is not and cannot be fully
trusted source.

> 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.

-- 
Pali Rohár
pali.rohar@xxxxxxxxx

-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.