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.ro...@gmail.com -- 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.