What happened in the failed integration tests was that the starting
process was not "minikube", it was "minikube-linux-" and
"minikube-darwin-" instead.
Since the test is failing on architectures/platform I can't reproduce
on.. I'm readapting the test in such a way to minimize the amount of
code that can be responsible for the error.
We're not looking for all system processes in order to find our
mount processes(ps -ef); we're looking directly at the mount
processes that have been spawned by our test instead.
To say that a process is no longer alive:
We try to wait for conclusion to get the processState.
If the wait results in an *ExitError, it means that either
the proc has failed to run, or it exited failing(see doc);
in both cases we're happy.. since we previously made a check
to know that those same processes were alive.
also adds that pleasedontkillme pkg, for the trykillone to be
tested against, so that we can run unit tests cross-platform:
no sure exec.Command("sleep", ....) is avail on windows...
The message from the linter makes a good point..
we're storing a reference for the mount processes, but we're not
using them.. Thus the committed lines.
I copied as much code as I could from the previous tests
that seemed more alike to the one I was trying to build.
I put it inside the functional mount tests,
with the other mount-command related tests,
as I thought (as per comments on "TestFunctional()") it
could safely share a profile in parallel..
The delete mechanism called by the --kill flag logic
inside the minikube mount command, relies on a .mount-process file
inside the .minikube dotfolder in home directory.
For this to work, the mount should've been instantiated
by some mechanism that also creates the file; like
k8s.io/minikube/pkg/minikube/node.configureMounts()
To just add the local.WriteFile() logic from configureMounts()
is not enough for the usecase in #15778:
user's consequent "minikube mount" calls would break the cleaning
logic, since the file's content gets overwritten at each new call.
So on subsequent minikube mounts, a call to "minikube mount
--kill=true" would remove just the last pid, leaving the other
mounts unaltered, and no trace of them in any place...(leak?)
For the same mechanism to work here,
we should rely on some local.AppendFile() function, to add
separated pids consequently.
This way only "minikube mount" would use this new append logic,
leaving unaltered the other functions.
We now have a new behaviour for the .mount-process file,
in order to address this, we should modify the delete logic from
cmd/minikube/cmd/delete.go -- killProcess(),
so that we can both kill a single pid, as well as multiple
space-separated pids in the same way.
...
Ah yes..
we're slightly modifying the "minikube mount" RunE anon function,
in order to write the pid into the .mount-process file;
as well as modifying cluster.Mount()'s signature to accept the pid.
That should be more than safe, since cluster.Mount() is used only here
x7upLime
Steven Powell
dependabot[bot]
Medya Ghazizadeh
Steven Powell
minikube-bot