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

hyperkit: minikube VM time not in sync after host sleep #4064

Closed
efengx opened this issue Apr 6, 2019 · 4 comments
Closed

hyperkit: minikube VM time not in sync after host sleep #4064

efengx opened this issue Apr 6, 2019 · 4 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.

Comments

@efengx
Copy link

efengx commented Apr 6, 2019

problem

After the mac sleeps, the minikube time will stop running. After the mac is restored, the minikube time will be different from the mac time. This difference will cause the pods in the minikube that need time-dependent to not work properly.

fengxiangdeMacBook-Pro% date
Sat Apr  6 20:28:56 CST 2019
fengxiangdeMacBook-Pro% minikube ssh -- date
Fri Apr  5 21:56:46 CST 2019

system version:

fengxiangdeMacBook-Pro% sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.4
BuildVersion:   18E226
fengxiangdeMacBook-Pro% minikube version
minikube version: v0.35.0
fengxiangdeMacBook-Pro% kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T19:44:19Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a087698aa92f0b1", GitTreeState:"clean", BuildDate:"2019-02-28T13:30:26Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

minikube vm-driver

hyperkit

@tstromberg tstromberg changed the title Minikube time error after macos sleep hyperkit: minikube VM time not in sync after host sleep Apr 8, 2019
@tstromberg
Copy link
Contributor

Ooh, this one promises to be a fun one to sort out. There are at least 3 ways to handle host->guest time when waking up from sleep:

  • Quickly sync the guest to the host: this makes users happy, but causes lost cron jobs, and causes many programs to crash because they detect a crashing clock.

  • Leave the guest and host out of sync: this causes issues, as you've seen, with time-dependent jobs like cron. It also causes issues with SSL certificates, in my experience. :|

  • Slowly bring the guest into sync with the host: this eventually makes everyone happy, but finding the right value of acelleration is tricky.

Do you mind commenting on what exactly wasn't working as expected for you?

@tstromberg tstromberg added kind/bug Categorizes issue or PR as related to a bug. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. labels Apr 8, 2019
@efengx
Copy link
Author

efengx commented Apr 9, 2019

@tstromberg
Is this a problem? According to my understanding, time should be an adjustment that can be adjusted at any time without affecting the operation of minikube. Whether minikube can be seen as a whole. (Similar to I can adjust the time of mac os at will, this will not cause mac os to crash)

Time issues can cause unexpected results in Prometheus statistics.

Warning! Detected 241748.20 seconds time difference between your browser and the server. Prometheus relies on accurate time and time drift might cause unexpected query results.

@mjgallag
Copy link

This appears to be a duplicate of #1378.

@tstromberg
Copy link
Contributor

Closing as dupe of #1378 and raising the priority on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.
Projects
None yet
Development

No branches or pull requests

3 participants