'minikube image load -' leaves behind a poorly-named /tmp/build.NNNN.tar

[ebblake]

What Happened?

minikube image load - ends up storing a file in /tmp rather than in memory, and does not clean up that temporary file when the minikube cluster is later destroyed. When repeatedly creating and destroying minikube profiles in order to iteratively test tweaks to a particular image, this can result in /tmp filling up and causing the machine itself to run out of memory or disk space (depending on what backs /tmp). See https://gitlab.com/subprovisioner/subprovisioner/-/merge_requests/24 for a workaround added to bypass minikube's behavior.

What's more, while some of minikube's files in /tmp are obvious (such as /tmp/minikube_XXXX_0.log), the filename chosen for image load is not (/tmp/build.NNN.tar). It is always good practice to make temporary file names include details about where to look when trying to debug when /tmp gets full, and fixing the temporary file to be something like /tmp/minikube_load_build.NNN.tar would fit this bill better.

Attach the log file

log.txt

Operating System

Redhat/Fedora

Driver

Podman

[nirs]

Same issue with log files in /tmp:

$ ls /tmp/minikube_*.log | wc -l
87

$ ls /tmp/minikube_*.log | awk -F_ '{print $2}' | sort | uniq -c | sort -rn
     59 cp
     20 ssh
      2 kubectl
      1 version
      1 ssh-key
      1 profile
      1 ip
      1 delete
      1 completion

It think the first step is to store all files in /tmp/minikube/{user} directory. Then maybe keep only logs for the last N commands.

[afbjorklund]

minikube typically had one user.

Changing the names of the tmp files sounds good to me, should probably include if it is "image" or "build" too
Moving the logfiles is a different issue, and if using tmp-on-tmpfs you can use something like TMPDIR=/var/tmp

https://fedoraproject.org/wiki/Features/tmp-on-tmpfs

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.