Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time not synced in WSL2 - causing TLS issues #4149

rknightion opened this issue Jun 15, 2019 · 20 comments

Time not synced in WSL2 - causing TLS issues #4149

rknightion opened this issue Jun 15, 2019 · 20 comments


Copy link

@rknightion rknightion commented Jun 15, 2019

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

Copy link

@zigford zigford commented Jun 16, 2019

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

Copy link

@therealkenc therealkenc commented Jun 18, 2019

Copy link

@f1yn f1yn commented Aug 16, 2019

@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

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

Copy link

@Danioy Danioy commented Aug 23, 2019

ntpdate works on my desktop.

run sudo ntpdate

could it be automatically?

Copy link

@therealkenc therealkenc commented Aug 27, 2019

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.

Copy link

@cmeiklejohn cmeiklejohn commented Oct 10, 2019

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.

Copy link

@dumblerod dumblerod commented Dec 2, 2019

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.

Copy link

@ozkanaltuner ozkanaltuner commented Dec 28, 2019

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

Copy link

@Rhahkeem Rhahkeem commented Feb 4, 2020

yeah i can confirm this is not fixed in wsl2

Copy link

@johnterickson johnterickson commented Mar 1, 2020

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

Copy link

@edperry edperry commented May 4, 2020

just ran in to this too. :(

Copy link

@linuxrebel linuxrebel commented Jul 5, 2020

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.

Copy link

@linuxrebel linuxrebel commented Jul 5, 2020

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

Copy link

@Justin-DynamicD Justin-DynamicD commented Aug 5, 2020

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.

Copy link

@phfts phfts commented Aug 7, 2020

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?

Copy link

@rmrhz rmrhz commented Aug 8, 2020

@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

Copy link

@myxoh myxoh commented Oct 13, 2020

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

Copy link

@celowsky celowsky commented May 10, 2021

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

Copy link

@frei-x frei-x commented Jun 22, 2021

thank you

Copy link

@devedse devedse commented Dec 7, 2021

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" /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 😄 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests