BUG: Temporary files filling up /tmp
Calvin D. Webster
I have been having exactly the same problem.
No other application on my RHL workstation is so abusive with disk space
on /tmp.
After searching Yahoo, vmware.com, and manuals all I could find was a
claim that VMware "respects the global tmp variable" and a suggestion to
add the "tmpDirectory" variable to the config file. It wasn't specific
about which configuration file, though.
Too many things depend upon TMP=/tmp so I wasn't about to change that. I
submitted a bug report.
After several emails VMware customer support suggested that I insert
"tmpDirectory = (NewTmpDir)" in one of three places: (1)
/etc/vmware/config, (2) ~/.vmware/preferences, or (3) the VM *.cfg
When this failed, they suggested setting TMP in a terminal window and
starting vmware. This too failed.
Each time I set "tmpDirectory = /home/vm/tmp", which is world writable
and has several GB of space.
I completely un-installed vmware, erasing all traces of it before
re-installing it. Still fails.
I even installed it on another RHL machine and it did exactly the same
thing.
Regardless of what machine it's on, or which location I place the
variable "tmpDirectory" VMware ALWAYS places the excessively large
temporary files on /tmp.
I sent customer support copies of all the configuration files and a dump
of my environment, each showing the "tmpDirectory" set. They took this
to mean that I set them all at once, even though I've repeatedly told
them otherwise (not that it should make any difference since the
variable is set with the same value).
VMware customer support claims that they cannot duplicate the problem
and has decided to throw their hands up and label the problem
"resolved". They don't seem to listen when I tell them that I'm not the
only one experiencing this problem, even when I pointed to your post.
They simply ignored my claim.
There is one curious entry in all the vm logs that keeps bugging me:
VMX|Log for VMware Workstation pid=10816 version=unreleased
build=build-1790 option=Release.3.1.1
Note the "unreleased" version. Just to be sure that I had, in fact,
installed the correct build, I downloaded it again from their official
link before the un-install and re-install. A check of the log showed the
same entry after running the latest download. It was the same on the
second machine on which I installed VMware.
There have to be others with tmp-bloat out there. Maybe they just don't
realize it because they either run Linux in a single partition or have a
very large /tmp filesystem. Maybe they've contacted customer support and
had their problem "resolved" similarly to mine.
Have you actually resolved either of these issues?
(1) VMware not reclaiming /tmp space when done with it.
(2) Relocating the "tmpDirectory".
Do your vm logs show an "unreleased" version too? If not, where did you
download it from?
If I've overlooked something I'll eat crow and appologize, but as it
stands right now it looks to me like VMware is sticking their head in
the sand. The customer support representative was difficult to work with
too, because he was constantly contradicting himself from previous
messages and each new message pretended that none of the previous ones
existed. I had to constantly repeat myself.
Not a happy customer!
--Cal Webster
"Karsten M. Self" wrote:
>
> "Karsten M. Self" wrote:
> >
> > I am getting the error message "Temporary files for this VM are stored
> > in /tmp, which is on an almost full filesystem. Please free some disk
> > space."
>
> Ok. It's an undocumented feature.
>
> I'd changed the logging location for the VM to
> /var/logs/vmware/<vm_guest_os>. However, this directory wasn't
> writeable by the user running the VM. Apparently, logs were then
> silently redirected to /tmp, but file handling didn't occur properly,
> and copious spillage of bits ensued.
>
> The problems appear to be:
>
> - The user did something unexpected.
> - The application did not warn the user of this condition (failure on
> unwritable logs would
> be preferable -- with a message, of course).
> - The application proceeded to commit additional sins as it silently
> strode past the
> original mistake.
>
> OT comments -- even on a P6/188, performance is _much_ improved by going
> to full-screen mode with the VMWare-provided X driver. I haven't tried
> 32 color yet, but 8 bpp is working fine.
>
> --
> Karsten M. Self (kms...@ix.netcom.com)
>
> What part of "Gestalt" don't you understand?
> Welchen Teil von "Gestalt" verstehen Sie nicht?
>
> web: http://www.netcom.com/~kmself
> SAS/Linux: http://www.netcom.com/~kmself/SAS/SAS4Linux.html
>
> 12:03am up 3 days, 20:52, 6 users, load average: 1.00, 0.88, 0.72
Chuck Gladu
<cweb...@ec.rr.com> wrote:
>Hello Karsten:
>
>I have been having exactly the same problem.
>
>No other application on my RHL workstation is so abusive with disk space
>on /tmp.
That's because no other application of your RHL workstation uses as
much memory as VMware does.
The extreme usage of /tmp is normal for VMware and is not a bug at
all.
This is perfectly normal.
Build 1790 was a Release Candidate build. (thus the 'unreleased' tag)
When no further problems were found in 1790, it went straight from RC
to release with no changes. This includes the 'unreleased' tag.
I agree that it is a bit misleading, but don't worry, build 179 is the
correct released build.
>Just to be sure that I had, in fact,
>installed the correct build, I downloaded it again from their official
>link before the un-install and re-install. A check of the log showed the
>same entry after running the latest download. It was the same on the
>second machine on which I installed VMware.
>
>There have to be others with tmp-bloat out there. Maybe they just don't
>realize it because they either run Linux in a single partition or have a
>very large /tmp filesystem. Maybe they've contacted customer support and
>had their problem "resolved" similarly to mine.
Unfortunately it isn't that straightforward. For most users,
redirecting the /tmp usage works properly. But there still seem to be
a few people that it doesn't work for.
>
>Have you actually resolved either of these issues?
>
> (1) VMware not reclaiming /tmp space when done with it.
VMware has no such problem. The usage you are seeing in /tmp is
correct even though you do not see enough files to account for it.
VMware uses some 'tricks' in how they use /tmp space that result in
you not seeing the space that they have allocated.
(perhaps Petr or someone who understands it can explain it)
> (2) Relocating the "tmpDirectory".
This, on the other hand, does seem to be a bug. I have seen several
complaints from people who are having trouble relocating Vmware's /tmp
usage.
Unfortunately, just like VMware Support, I have no suggestion to help
you since it seems to work properly for almost everyone. There
doesn't seem to be enough evidence yet to determine what is common to
the few people who have the problem.
>
>Do your vm logs show an "unreleased" version too? If not, where did you
>download it from?
Unfortunately, it will show 'unreleased' for all users of build 1790.
It is the correct, released version. VMware just failed to fix the
tag when 3.1.1 was formally released.
>
>If I've overlooked something I'll eat crow and appologize, but as it
>stands right now it looks to me like VMware is sticking their head in
>the sand. The customer support representative was difficult to work with
>too, because he was constantly contradicting himself from previous
>messages and each new message pretended that none of the previous ones
>existed. I had to constantly repeat myself.
I'm sorry that VMware's customer support gave you such a bad
experience.
My suggestion would be to take a deep breath, let the anger go, and
try to enlist the aid of Petr (from these newsgroups).
He doesn't get paid to support VMware (so please remember to be nice
to him), but if anyone can help you with your problem....he probably
can.
There seems to be very little related to VMware on Linux hosts that
Petr can't figure out/fix.
----
Chuck Gladu
Do NOT reply to me by e-mail.
Please note: I do NOT work for VMware.
I'm a customer just like you are.
Petr Vandrovec
> >Have you actually resolved either of these issues?
> >
> > (1) VMware not reclaiming /tmp space when done with it.
>
> VMware has no such problem. The usage you are seeing in /tmp is
> correct even though you do not see enough files to account for it.
>
> VMware uses some 'tricks' in how they use /tmp space that result in
> you not seeing the space that they have allocated.
>
> (perhaps Petr or someone who understands it can explain it)
It creates backing file for your machine here and unlinks it, so
it is not visible and is released when vmware is killed. If you'll
suspend machine, exit vmware, start vmware & resume machine,
it will use .std (checkpoint) file as main backing storage, instead
of /tmp/ram0.
> > (2) Relocating the "tmpDirectory".
>
> This, on the other hand, does seem to be a bug. I have seen several
> complaints from people who are having trouble relocating Vmware's /tmp
> usage.
What happens if you do:
mkdir /asd
mktemp -p /asd
It should say something like
/asd/tmp.XXXXfHM8v4
If it says /tmp/tmp.XXXXfHM8v4 on your system, complain to your libc vendor.
Petr
Jim Simmons
with "tmpDirectory = whatever". That file doesn't exist by default
under Linux (or it didn't for me anyway).
Don't put it in ~/vmware/preferences or the .cfg file for the virtual
machine.
Also, regardless of what the vmware instructions say, it does NOT use
the TMPDIR environment variable, or at least it didn't for me. I'm
running VMWare Workstation for Linux version 3.1.1 built-1790.
It's easy to confirm it is working by using "lsof" after you start your
virtual machine. It still puts something very small in /tmp but ram0
now goes where you want it to.
Jim