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

Disable minikube-scheduled-stop.service until a user schedules a stop #9865

Closed
afbjorklund opened this issue Dec 5, 2020 · 10 comments · Fixed by #10548
Closed

Disable minikube-scheduled-stop.service until a user schedules a stop #9865

afbjorklund opened this issue Dec 5, 2020 · 10 comments · Fixed by #10548
Assignees
Labels
co/docker-driver Issues related to kubernetes in container good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/bug Categorizes issue or PR as related to a bug. priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@afbjorklund
Copy link
Collaborator

The environment file is missing:

● minikube-scheduled-stop.service - m/var/lib/minikube/scheduled-stop/environmentinikube scheduled stop
     Loaded: loaded (/lib/systemd/system/minikube-scheduled-stop.service; enabled; vendor preset: enabled)
     Active: failed (Result: resources)

Dec 05 16:01:44 docker systemd[1]: minikube-scheduled-stop.service: Failed to load environment files: No such file or directory

Dec 05 16:01:44 docker systemd[1]: minikube-scheduled-stop.service: Failed to run 'start' task: No such file or direc
tory
Dec 05 16:01:44 docker systemd[1]: minikube-scheduled-stop.service: Failed with result 'resources'.
Dec 05 16:01:44 docker systemd[1]: Failed to start minikube scheduled stop.

It needs to have a - in front:

EnvironmentFile=-/var/lib/minikube/scheduled-stop/environment

@afbjorklund afbjorklund added co/docker-driver Issues related to kubernetes in container kind/bug Categorizes issue or PR as related to a bug. labels Dec 5, 2020
@afbjorklund
Copy link
Collaborator Author

Something for you, @priyawadhwa ?

@priyawadhwa
Copy link

priyawadhwa commented Dec 6, 2020

Yup that's for me! Did this happen before or after you tried to schedule a stop?

If before, it's not technically a bug since we copy in the env file when a user runs

minikube stop --schedule <duration>

(kind of ugly that the service says a failure though if that's the case, the service doesn't really need to be started until someone tries to schedule a stop)

@afbjorklund
Copy link
Collaborator Author

It happened on boot of a brand new cluster

@priyawadhwa
Copy link

That makes sense, since the file hasn't been copied over yet.

Best way to fix this is probably to disable the systemd service so it doesn't start on boot, and then enable it the first time user runs minikube stop --schedule

@priyawadhwa priyawadhwa changed the title New minikube-scheduled-stop.service fails to start in docker Disable minikube-scheduled-stop.service until a user schedules a stop Dec 7, 2020
@priyawadhwa priyawadhwa added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Dec 7, 2020
@priyawadhwa priyawadhwa mentioned this issue Dec 8, 2020
4 tasks
@tharun208
Copy link
Contributor

@priyawadhwa I like to work on this

@priyawadhwa
Copy link

priyawadhwa commented Dec 8, 2020

Thanks @tharun208 ! Some steps you will need to take:

  1. We want to make sure minikube-scheduled-stop.service doesn't start on boot, so that will likely require a change in both of our systemd service files:
  1. When we do run minikube stop --schedule 3m, we will probably need to enable the service before we start it, which would happen before we restart the service here:

return sysManger.Restart(constants.ScheduledStopSystemdService)

@tstromberg tstromberg added the priority/backlog Higher priority than priority/awaiting-more-evidence. label Dec 11, 2020
@afbjorklund
Copy link
Collaborator Author

systemd has a weird way from stopping services to get enabled by default:
https://www.freedesktop.org/software/systemd/man/systemd.preset.html

@medyagh
Copy link
Member

medyagh commented Feb 11, 2021

@tharun208 I haven't heard from you, meanwhile I assign this to @jiefenghe please feel free to start working on this

@jiefenghe
Copy link
Contributor

/assign

@jiefenghe
Copy link
Contributor

jiefenghe commented Feb 18, 2021

systemd has a weird way from stopping services to get enabled by default:
https://www.freedesktop.org/software/systemd/man/systemd.preset.html

Then my understanding is to add a 50-minikube.preset file with disable minikube-scheduled-stop.service to disable it by default.

But since the suggested enable step in minikube/pkg/minikube/schedule/daemonize_windows.go is only for windows. Do we need to enable the service in linux? Where is the code for that? Why the issue only exist for windows?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
co/docker-driver Issues related to kubernetes in container good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/bug Categorizes issue or PR as related to a bug. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
6 participants