Time not synced in WSL2 - causing TLS issues

[rknightion]

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

If you have a feature request, please post to the UserVoice.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".

Please fill out the below information:

• Your Windows build number: [Version 10.0.18917.1000]

• What you're doing and what's happening:

Was having issues with SSL certificates in k8s "Unable to connect to the server: x509: certificate has expired or is not yet valid"
Spent ages debugging on servers. Turned out the time in my WSL2 prompt I was using to access the external cluster had the wrong time.
In WSL2 (ubuntu build)

rob@SUSE-Dell:~$ date
Sat Jun 15 10:08:45 BST 2019

In Windows (run literally 1 second after)

PS C:\Users\rob> date
15 June 2019 22:24:14

• What's wrong / what should be happening instead:
  Date should be synced up, as it was for WSL1

Not sure if the OS image makers should be dealing with this, but I guess if things are running in some kind of VM now some kind of time drift will happen (this issue wasn't happening ~12hrs ago). This ubuntu image was converted from WSL1 > 2.

Solved my issues for now running a manual ntp sync (which is sudo ntpdate -b time.google.com for anyone interested, but with the lack of systemd/daemon I'll have to keep doing this every time the drift gets too great. In other vm platforms there's mechanisms in place for keeping time in sync and as a user it would be good to have the system take care of this autoamtically

[zigford]

I left my laptop sleep for a few days with a WSL2 distro open. When I resumed tonight, the date was out of sync by 2 days. My distro did not have ntpdate installed, and apt-get tools were failing due to TLS issues. Workaround: wsl --shutdown to force the VM to close and then reopen WSL

[therealkenc]

#4114

[f1yn]

@rssfed23 @zigford This works for Ubuntu in WSL 2, without losing your running processes. (should also work in most distros, though you'd need to use your own package managers)

sudo apt install ntpdate
sudo ntpdate -sb time.nist.gov

Then run sudo ntpdate -sb time.nist.gov each time you want to correct the drift.

[Danioy]

ntpdate works on my desktop.

run sudo ntpdate time.windows.com

could it be automatically?

[therealkenc]

could it be automatically?

You could stash it in your .bashrc with and use sudoers. That way it'd at least run each time you fire up a shell, which isn't ideal but would probably suffice.

[cmeiklejohn]

I'm running into massive drift: it's 13:49 as reported by Windows and 23:54 as reported by WSL 2 in build 18995.

[dumblerod]

I'm confused. This still isn't fixed as of 19033.1 using WSL2. Manually fixing the drift by running a command is not a resolution to the problem since it will just get out of sync again.

[ozkanaltuner]

I'm on build 19536 and can confirm that WSL2 time sync problem still exists

[Rhahkeem]

yeah i can confirm this is not fixed in wsl2

[johnterickson]

Not on the WSL team myself, but this it looks like this issue is being closed because it is being tracked at #4114.

[edperry]

just ran in to this too. :(

[linuxrebel]

Still an issue with WSL2 on current Windows 10 stable
Windows 10 Pro
Version 2004
Installed on 06/26/2020
OS Build 19041.330
Experience Windows Feature Experience Pack 120.2202.230.0

Running both Linux and Windows date commands back to back I get the following

J360:~: Ubuntu 20.04 LTS ┐
└ 03:53 PM james $ date; date.exe
Sat Jul 4 15:58:06 PDT 2020
Sun Jul 5 01:16:36 Pacific Daylight Time 2020

The time diff is approximately the time I put the system to sleep. With an open Ubuntu terminal window. If I close the window, then in powershell do a wsl.exe --shutdown Ubuntu Then start a new Ubuntu shell. I get

J360:~: Ubuntu 20.04 LTS ┐
└ 01:19 AM james $ date; date.exe
Sun Jul 5 01:20:30 PDT 2020
Sun Jul 5 01:20:30 Pacific Daylight Time 2020

so it does seem that what is happening is that when the laptop sleeps, time, for the wsl session freezes. Upon wakeup, it starts up where it left off. X hours behind dependent upon the amount of sleep.