[Linux-aus] Ubuntu 20.04 resume time problem

[Eyal Lebedinsky]

On 06/07/2022 18.57, Norberto Meijome via linux-aus wrote:
>  > With systemd-timesyncd it takes some time to get back to the right time,
>  > sometimes more than 10 minutes.
> 
> Hi,
> seeing the obvious/expected fixes have failed, I feel less squeamish to suggest an exec of ntpdate on wake and after network service is up. I hoped you could also tweak how aggressively systemd.timesyncd drifts the clock but its config seems quite minimal (only man page checked though).

I see this problem regularly when I boot a windows laptop after running Linux from SSD.
Linux seems to sort this out OK on boot but not windows.

However, when a linux kvm is resumed it does not adjust the time, so my wakeup script issues,
following the 'virsh restore':
	ssh eyal at e4 'sudo ntpdate -bu time.iinet.net.au'
I did not find a simpler solution when I looked into it a few years ago.

> good luck,
> B
> 
> On Wed, 6 Jul 2022 at 17:45, Russell Coker via linux-aus <linux-aus at lists.linux.org.au <mailto:linux-aus at lists.linux.org.au>> wrote:
> 
>     On Tuesday, 28 June 2022 13:30:57 AEST NeilBrown via linux-aus wrote:
>      > On Tue, 28 Jun 2022, Russell Coker wrote:
>      > > I have a laptop that is dual boot Ubuntu 20.04 and Windows. I've
>      > > configured it for "RTC in local TZ" with timedatectl so it can have the
>      > > same time as Windows (I'm aware that I could change Windows via regedit
>      > > to use UTC for the hwclock but I'm trying to work out the best option for
>      > > a corporate rollout).  The problem is that I resume from suspend and the
>      > > system immediately treats the RTC as if it was in UTC thus being out by
>      > > 10 hours (time zone +1000).
>      > >
>      > > How does Ubuntu get the time from the RTC on resume? Any clues as to where
>      > > to look would be really appreciated. I've done Google searches and found
>      > > nothing helpful. Even if you just know which program does it that would
>      > > help a lot, I could read the source.
>      >
>      > It isn't up to Ubuntu - the Linux kernel does (or should do) everything
>      > needed.
>      > Providing the kernel is built with CONFIG_PM_SLEEP and
>      > CONFIG_RTC_HCTOSYS_DEVICE, and providing you have RTC hardware with a
>      > suitable driver, then on suspend rtc_suspend() in drivers/rtc/class.c
>      > will take note of the value stored in the rtc, and on resume
>      > rtc_resume() will check what the difference was and update the clock.
>      >
>      > cat /sys/class/rtc/rtc0/hctosys
>      >
>      > should show "1" if everythings is configured properly.  In that case it
>      > should "just work".
> 
>     It does show "1" and the kernel build options include those ones you specify,
>     but unfortunately it doesn't "just work".
> 
>     NTP the protocol allows fixing this with the systemd-timesyncd implementation,
>     the ntpd implementation gets unhappy when the time is more than 20 minutes
>     out.  With systemd-timesyncd it takes some time to get back to the right time,
>     sometimes more than 10 minutes.
> 
>     I have not seen this cause a SSL problem.  When this happens Kerberos is no
>     more broken than usual (that's another issue I have to solve).
> 
>     Yes I know that using the local time for the RTC has some downsides, but every
>     option for dual boot has some downsides.
> 
>     Thanks for the suggestions.
> 
>     -- 
>     My Main Blog http://etbe.coker.com.au/ <http://etbe.coker.com.au/>
>     My Documents Blog http://doc.coker.com.au/ <http://doc.coker.com.au/>

-- 
Eyal Lebedinsky (linux at eyal.emu.id.au)