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.

[linuxrebel]

Further testing. time "freeze" only occurs if you have a WSL window open when the laptop sleeps.

[Justin-DynamicD]

Adding voice to the opinion that this should not be closed. Using WSL2 and if I shutdown my laptop, WSL2 will drift implying that it doesn't know how to recover from having no hwclock.

I've not tested different distros to see if perhaps that's to blame, but ubuntu 18.04 LTS definitely has the problem.

[phfts]

Still having same issue. It was pointed to put in .bashrc but it seems to be necessary to input sudo password every time a new shell is opened. Have you guys found a better solution?

[rmrhz]

@paulosoares86 you could assign a NOPASSWD in a /etc/sudoers file. My .bash_profile runs sudo hwclock -s. Then in /etc/sudoers.d/username_hwclock

username ALL=(ALL) NOPASSWD: /sbin/hwclock

[myxoh]

This other issue seems to be tracking the same problem: #5324 for those landing here from Google

[celowsky]

Also ran into this and kept me confused for quite a while while I was trying to determine how my OAuth tokens were being invalidated so quickly

[frei-x]

thank you

[devedse]

Hi all, I created a script that creates a scheduled task to automatically update the time of WSL when you either restore from sleep or you restore a "Saved" Hyper-V VM.

wsl -d Ubuntu -u root apt-get update && apt-get install ntpdate
schtasks /Create /TN wsl-clock /TR "wsl -d Ubuntu -u root ntpdate pool.ntp.org" /SC ONEVENT /EC System /MO "*[System[Provider[@Name='Microsoft-Windows-Kernel-Power'] and (EventID=107 or EventID=507) or Provider[@Name='Microsoft-Windows-Kernel-General'] and (EventID=1)]]" /F

Change Ubuntu (in both places in the script) to the name of your WSL Instance (See wsl --list), then execute the script in cmd.

Thanks to all the other comments/suggestions that helped me create this script 😄 .

[fahmieshaq]

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

Your solution worked like a charm

[not4fame]

Hello, after the recent Win 11 update, the problem reappeared on Ubuntu in WSL 2, only hwclock -s helps.

[michaelarnauts]

@not4fame See #8204 for a new issue.

[honsa]

Still occurs.

Solution is to switch to a working Linux Machine and throw Microsoft from system