Improve user feedback for slow docker operations during delete

[skartikey]

Description:

Fixes #19577

Problem

When docker daemon is slow or unresponsive, minikube delete operations hang indefinitely without providing feedback to users. This leads to confusion where users don't know if minikube is working or stuck.

Solution

Enhanced docker command execution to provide immediate feedback and prevent infinite hangs:

• Show warning messages after 2-3 seconds when docker commands are slow
• Automatically timeout and terminate hanging processes after 19-30 seconds
• Provide helpful guidance about restarting docker service
• Enable warning mode for all delete-related container operations

Before:

$ minikube delete --all
🔥  Deleting "test-profile" in docker ...
🔥  Deleting container "test-profile" ...
[hangs indefinitely with no feedback when docker is slow]

After:

$ minikube delete --all
🔥  Deleting "test-profile" in docker ...
🔥  Deleting container "test-profile" ...
❗  "docker ps -a --filter label=name.minikube.sigs.k8s.io=test-profile --format {{.Names}}" is taking an unusually long time to respond, please be patient.
💡  If this continues to hang, consider restarting the docker service.
❗  "docker ps -a --filter label=name.minikube.sigs.k8s.io=test-profile --format {{.Names}}" took too long to respond (>30s) and was terminated.
💡  Consider restarting the docker service if this problem persists.
💀  Removed all traces of the "test-profile" cluster.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: skartikey
Once this PR has been reviewed and has the lgtm label, please assign prezha for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @skartikey!

It looks like this is your first PR to kubernetes/minikube 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/minikube has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @skartikey. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[minikube-bot]

Can one of the admins verify this patch?

[medyagh]

thank you for this PR please take a look at the unit test
"make test"

cli_runner_test.go:44: runCmd does not print the correct log, instead print :! "sleep 3" is taking an unusually long time to respond, please be patient.

[medyagh]

this doesnt seem right, "sudo" could mean a lot of things, doesnt mean podman on linux, this check probably adds more harm than good

[skartikey]

@medyagh Thanks for the feedback! You're right that hardcoding "sudo" string comparison isn't ideal in general. However, I kept this approach because it's already consistently used throughout the codebase:

1. Existing pattern in PrefixCmd(): The code already explicitly adds "sudo" as a string literal:

   cmdWithSudo := exec.Command("sudo", append(append([]string{"-n"}, o.sudoFlags...), cmd.Args...)...)

2. Controlled context: Since minikube controls the command construction through PrefixCmd(), we know exactly when and how "sudo" is added.

3. Limited scope: This helper function only processes commands that minikube itself constructs.

I've added a comment to clarify this:

// If not using sudo, return the first argument
// Note: This checks for "sudo" specifically because PrefixCmd() 
// explicitly adds "sudo" as a string literal when needed
if cmdArgs[0] != "sudo" {
    return cmdArgs[0]
}

That said, if you have a preferred alternative approach for identifying the actual OCI binary name when sudo is involved, I'm happy to implement it. Some options could be:

• Using filepath.Base() to check just the binary name
• Passing a flag from PrefixCmd() indicating if sudo was added
• A different method altogether

What would you prefer?

[medyagh]

/test

[k8s-ci-robot]

@medyagh: The /test command needs one or more targets.
The following commands are available to trigger required jobs:

/test pull-minikube-build

The following commands are available to trigger optional jobs:

/test pull-minikube-platform-tests

Use /test all to run the following jobs that were automatically triggered:

pull-minikube-build

In response to this:

/test

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.