[go: up one dir, main page]

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

Unable to manually change system time in WSL: automatic sync with Windows overrides changes #11318

Closed
1 of 2 tasks
abtswath opened this issue Mar 18, 2024 · 2 comments
Closed
1 of 2 tasks

Comments

@abtswath
Copy link

Windows Version

Microsoft Windows [Version 10.0.22631.3296]

WSL Version

2.1.5.0

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

Kernel Version

5.15.146.1

Distro Version

Debian GNU/Linux 12

Other Software

No response

Repro Steps

I changed the system time to test a program.

  1. Turn off the automatic time sync service, like systemd-timesyncd.
  2. Use the date -s command or timedatectl set-time command to modify the time.

Expected Behavior

I'm not entirely sure if this really counts as a problem because I found out it's actually a patch introduced to fix issue #10006. Also, when I set the kernel parameter hv_utils.timesync_implicit=0, the time won't automatically sync with Windows time.

Actual Behavior

A few seconds later, check the current time using the date command, the system time gets synced back to the Windows time.

Diagnostic Logs

No response

Copy link

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

@ghost
Copy link
ghost commented Mar 19, 2024

As you noticed, we changed things. I'm glad you found hv_utils.timesync_implicit=0 but I'm going to close this as by design. In an ideal world the hypervisor would have been patched, and you wouldn't notice this till a major power event happens.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant