Vagrant: cleanup /tmp

[berendt]

After some time using Vagrant on one of my boxes (I don't reboot this box) my /tmp directory looks really terrible. There are a lot of files and directories prefixed with vagrant. I think Vagrant should remove the files and directories by itself.

berendt@zitrone /tmp % ls -l | grep vagrant | wc -l
5494

[mitchellh]

It isn't really Vagrant's responsibility to do this. The idea, I believe, behind a temp directory is that it will be cleared out periodically so persistent data shouldn't go there. I recommend setting up a cron.

That being said, Vagrant should do its best to clean up where it can (there are some cases it can't). If you can find specific cases of this, please let me know, and I'll keep an eye out, too.

[andylowry]

I can understand the reasoning behind this not being a bug. But it would be far nicer for vagrant to put all its tmp files and directories under a common directory, rather than at top level. After a heavy day of using vagrant to run clusters on AWS I've got nearly 1500 vagrant files & directories in /tmp, which makes working in /tmp for any other reason very annoying.

[valchonedelchev]

As it seems these tmp files are created on every command. e.g.:

$ ls -al /tmp/vagrant*|wc -l
ls: cannot access /tmp/vagrant*: No such file or directory
0

vagrant status
Current machine states:
web                       running (virtualbox)
app                       running (virtualbox)
test                      running (virtualbox)

$ ls -al /tmp/vagrant*|wc -l
4

$ vagrant ssh web -- date
...output goes here
$ ls -al /tmp/vagrant*|wc -l
9

$ vagrant box outdated
... output...
$ ls -al /tmp/vagrant*|wc -l
13

The only difference is the number of tmp file, on status I got +4 but on ssh command I got +5. The file names are in the following format: /tmp/vagrantYYYMMDD-PID-RAND and /tmp/vagrantYYYMMDD-PID-RAND.lock

$ vagrant version
Installed Version: 1.7.1

[berendt]

Can we please re-open this issue and handle it as a feature request?

ll /tmp/vagrant* | wc -l
1322

[valchonedelchev]

Check this out: https://github.com/valchonedelchev/vagrant/commit/b220de5bf8ee96c64aee2a245f598c1f06d6cec0

[valchonedelchev]

One more temp file clean up from /tmp - https://github.com/valchonedelchev/vagrant/commit/19d34bb0721abf6199079e61abf00f4a9e09eaa6

[berendt]

@valchonedelchev Cool. Let's up a pull request for this and link it to this issue. I will try to test it later this week.

[valchonedelchev]

It reduces the number of files in /tmp to 1 instead of 5 especially when running vagrant ssh command. I believe the last remaining temp file is somehow related to this TODO here https://github.com/mitchellh/vagrant/blob/master/lib/vagrant/bundler.rb#L229.

[TomyLobo]

It isn't really Vagrant's responsibility to do this.

Yes it is and I will explain why.

The idea, I believe, behind a temp directory is that it will be cleared out periodically

The idea behind a temp directory is that there will be temporary files in there.
The FHS recommends cleanup on boot, not periodically.
And since it's only a recommendation, not a requirement, you cannot even rely on _that_.

so persistent data shouldn't go there.

The FHS confirms that part.

I recommend setting up a cron.

As said before, that is not the recommendation the FHS makes.
Additionally, you cannot really distinguish used from unused files in such a cleanup cronjob.
You can verify whether the creator of the file is still around, but I doubt very many OSes do that by default, so you cannot rely on that being the case when writing your program.
The only one who can be sure a file is not needed anymore is the creator of said file.

I compare this to memory leaks. Sure, the OS deallocates all your memory when the process exits, but a good program frees unused memory anyway.

That being said, Vagrant should do its best to clean up where it can (there are some cases it can't).

Does any of these cases apply to regular invocation and termination of a command, say vagrant ssh?

Some statistics that motivate my comment:

• There have been reports of slowdowns on file access to /tmp in unrelated applications.
• /tmp contains 45194 vagrant* files/dirs
• 2 of them are vagrant-gemfile*.lock
• of the remainder, 9912 are vagrant*.lock
• there are 35280 other vagrant* files/dirs.
• In addition to that, there are 11290 d201* directories, which are also from Vagrant
• uptime is 52 days

Meaning it leaked 869 temporary files a day, on average.
I run like 10 vagrant commands a day.
Imagine someone spinning up vagrant boxes for hourly integration tests.

[berendt]

@TomyLobo Thanks for your explanation and motivation. Maybe it helps to re-open this issue.

[wzyboy]

If an automatic clean-up or something is not feasible now, it would still help a lot if Vagrant could be configured to save temp files in a sub-directory like /tmp/vagrant/, not under the /tmp/ directly.

I work with my team through Slack. Often, I grab a screenshot and save it to /tmp/ directory before uploading it to a Slack channel, keeping in mind that these screenshots would be deleted automatically on next reboot (/tmp is mounted in tmpfs in Arch Linux by default). However, Vagrant making tons of temp files directly under /tmp/ directory makes my selection of the screenshot I just took hard and frustrating.

Even an environment variable like $VAGRANT_TEMP_DIR would help. Just my two cents.

[TomyLobo]

@wzyboy that's a great idea. I support it.

[ryanmjacobs]

I store a lot of files in /tmp so I don't wear out my hard-drive. And I hate having to run rm /tmp/vagrant*, just so I can see the output of an ls.

I think that @wzyboy's has a good solution. Maybe a sane default would be /tmp/vagrant.d/? It certainly would be the easiest solution to implement, (but maybe not the most correct one).

[nogweii]

I'm trying to track down where there are "temp file leaks", using @TomyLobo words. Looking at the source code, it seems that whenever Vagrant::Bundler uses Tempfile it leaks a file. It seems like https://github.com/mitchellh/vagrant/commit/04835ae612b9a37297101297cae22b542a79feca didn't catch everything. There have been prior attempts at solving this, but it has caused regressions in the past (see #4869) so other PRs will of course need to be careful.

See also: #6301, #6231