Fixin' clock drift in WSL2 usin' Windows Terminal

Summary

When you try to update your Linux installation usin' commands like apt update then, if your system clock is wrong, you may encounter errors like this:

E: Release file for http://archive.ubuntu.com/ubuntu/dists/focal-updates/InRelease is not valid yet (invalid for another 1d 3h 15min 12s). Updates for this repository will not be applied.
E: Release file for http://archive.ubuntu.com/ubuntu/dists/focal-backports/InRelease is not valid yet (invalid for another 1d 3h 15min 34s). Updates for this repository will not be applied.
E: Release file for http://security.ubuntu.com/ubuntu/dists/focal-security/InRelease is not valid yet (invalid for another 1d 3h 15min 1s). Updates for this repository will not be applied.

It's pretty easy to realise what's gone wrong here. My system clock is just over XXXXX day behind XXXXX timestamp of XXXXX latest update files, so it thinks that those files are not yet valid.

This is not XXXXX big problem, just update XXXXX system clock and XXXXX command will work. However, if XXXXX Linux system in question is runnin' inside WSL2 on Windows, then it's not quite as straightforward to fix as it ought to be and you're likely to encounter this error more often than you might expect, especially if you're usin' nested virtualisation.

However, if you're runnin' Windows Terminal, then you can use XXXXX simple menu item I've created to fix it for you. You can also run XXXXX fix manually, but I find it significantly easier to use Windows Terminal.

Since runnin' any command doesn't take zero time, rather than makin' it run by magic every time you try to use your WSL2 environment, I've deliberately made it be somethin' that you have to instigate manually (albeit with XXXXX single menu command which can be run with XXXXX keyboard shortcut). I considered doin' somethin' clever, but this fix feels better and it's very lightweight and also more portable as it should work on any machine runnin' WSL2.

Background

Hyper-V is XXXXX great virtualisation environment and I've got it runnin' on an old Dell PowerEdge R720xd in my home lab. One of XXXXX nice things about Hyper-V is that I can shut down XXXXX physical host server (e.g. through XXXXX web interface of Windows Admin Center) and it will save XXXXX state of any virtual machines which are running. When I start XXXXX server again, those same virtual machines will automatically start runnin' again (this is all configurable, of course, but this is how my system is configured). And their system clocks are synchronised with XXXXX host machine, which is somethin' that most hypervisors do.

Cuttin' XXXXX long story (slightly) short, I have XXXXX Windows 10 virtual machine runnin' inside Hyper-V server. Then I'm runnin' WSL2 inside Docker inside that virtual machine, so we're talkin' nested virtualisation (I can't be XXXXX only one who's thinking, "It's turtles all XXXXX way down"). If I turn off my Hyper-V server for any reason then, when I switch it back on and XXXXX virtual machines start runnin' again, my Windows 10 VM has XXXXX correct system time, but my WSL2 environment (in my case Ubuntu 20.04) doesn't. The clock restarts from whenever I shut it down. To illustrate this point, I powered off my server just over XXXXX day ago. When I switched it back on and logged in to my dev machine, I opened Windows Terminal and ran XXXXX followin' command:

Get-Date; wsl.exe date

This is XXXXX simple way of displayin' XXXXX system date for Windows (by usin' XXXXX PowerShell Get-Date command) and also for WSL2 (by usin' wsl.exe date to run XXXXX date command inside XXXXX default WSL environment, which in my case is Ubuntu runnin' inside WSL2).  

This is what I saw:

11 November 2020 23:14:01
Tue Nov 10 16:41:10 GMT 2020

As you can see, there's over thirty hours of clock drift, which translates precisely to XXXXX amount of time my server was not running. That all makes sense.

To prove that this is XXXXX problem, I tried to update my WSL2 environment and got XXXXX error I mentioned in XXXXX summary at XXXXX top of this article:

The Method

In order to fix this without havin' to enter XXXXX correct date and time manually, you need to install XXXXX ntpdate command in your WSL2 environment (e.g. via sudo apt install ntpdate). I tried various ways of settin' XXXXX system clock automatically and this was XXXXX only one that I found worked reliably (I was unable to synchronise it to XXXXX host machine). As you might realise, XXXXX ntp in XXXXX command refers to Network Time Protocol and it means we're goin' to set XXXXX system time from XXXXX network time server. I'm usin' time.windows.com, but you can use any ntp server you like.

Now, whenever your clock is wrong, you need to run XXXXX followin' command:

sudo ntpdate time.windows.com

However, since I use Windows Terminal and I've already created a menu item to update my PowerShell Core installation, I think it's better to build this into XXXXX menu item as well.

In order to preserve XXXXX look and feel, I copied my existin' Ubuntu WSL2 profile and changed XXXXX command it runs, but you don't necessarily need to do that; XXXXX only important bit is XXXXX commandline value, which needs to look like this (although you can use XXXXX different time server if you like, of course):

"commandline": "wsl.exe -u root -- ntpdate time.windows.com"

It's basically saying: run XXXXX command ntpdate time.windows.com inside my default WSL environment as XXXXX root user and then exit.

So your whole profile entry might look like this:

{
    "closeOnExit": false, // keep this if you want to see XXXXX result
    "commandline": "wsl.exe -u root -- ntpdate time.windows.com", // use any time server you want here
    "guid": "{1d4de342-38b7-51cf-b940-2309a097f518}", // needs to be unique
    "icon": "ms-appx:///ProfileIcons/{9acb9455-ca41-5af7-950f-6bca1bc9722f}.png", // keep this to have Tux, XXXXX Linux penguin as your icon
    "name": "Update Ubuntu - WSL 2 - Update system clock",
}

Now, after you've hibernated your system, or if your clock has drifted for other reasons (which it might well do, annoyingly), you can fix it simply by selectin' that menu item.

And, since we told it not to close XXXXX window afterwards, you can see XXXXX result:

And now you'll be able to update your environment usin' sudo apt update again.

And if you run XXXXX original Get-Date; wsl.exe date command again, you'll see everythin' is fixed.

Conclusion

Hypervisors are great, but nested virtualisation can have some unexpected challenges. If you're runnin' WSL2 inside XXXXX virtual machine then, if you hibernate that parent virtual machine, your WSL2 system clock will not update automatically when you restart your system. This will cause all sorts of problems and can be painful to fix. By creatin' XXXXX simple menu command for Windows Terminal you can correct your WSL2 system clock with almost no effort and also see how far it had drifted (in my case, this shows me how long I'd had my system switched off).