Left over files in /tmp? (vmware-config##, vmware-fonts##, vmware-root)

[ventz]

I noticed /tmp was full of things like:

vmware-config0 vmware-config27 vmware-fonts10 vmware-fonts29 vmware-config1 vmware-config28 vmware-fonts100 vmware-fonts3 vmware-config10 vmware-config29 vmware-fonts101 vmware-fonts30

Just wondering if I am doing something incorrectly or this is normal? If so, is there a way that this can be either cleaned up or at worst, contained in /tmp/vmware-temp?

[craigwatson]

I believe these folders are actually left over from the vmware-config-tools.pl script.

I could alter the module to clean up /tmp/vmware-* but I'd rather not use wildcards.

Can you check the size of these directories?

[ventz]

Interesting. They are very small. Maybe even just organizing them in a single folder would do.

The config is ~8K: Contain only a file called: "99-vmware-scsi-udev.rules" (~4K)

which is:

VMware SCSI devices Timeout adjustment

Modify the timeout value for VMware SCSI devices so that in the event of a failover, we don't time out. See Bug 271286 for more information.

ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware ", ATTRS{model}=="Virtual disk ", RUN+="/bin/sh -c 'echo 180 >/sys$DEVPATH/timeout'"

I am curious why these just started showing up though, because I am assuming vmware-config-tools.pl ran before? Or is it that it only ran once where as now it's running on each puppet checkin?

The other one that's new is the /tmp/vmware-root seems not to be deleting the old appLoader-##### and setup-##### files, and just collecting hundreds of them.

It's almost like something is running multiple times that should only run once?

[craigwatson]

Can you check your Puppet runs to see if the vm-config-tools.pl is running multiple times, and if it is, can you check the existence of /lib/modules/${::kernelrelease}/misc/vmci.ko?

[ventz]

It looks like that is the case

Manual run with debug (just the relevant part):

Info: Applying configuration version '1383560879' Debug: Prefetching apt resources for package Debug: Executing '/usr/bin/dpkg-query-W--showformat'${Status} ${Package} ${Version} :DESC: ${Description}\n:DESC:\n'' Debug: Execvmware_config_tools: Executing '/usr/bin/vmware-config-tools.pl -d' Debug: Executing '/usr/bin/vmware-config-tools.pl -d' Notice: /Stage[main]/Vmwaretools::Config_tools/Exec[vmware_config_tools]/returns: executed successfully Debug: /Stage[main]/Vmwaretools::Config_tools/Exec[vmware_config_tools]: The container Class[Vmwaretools::Config_tools] will propagate my refresh event

I have a vmci.o: /lib/modules/3.2.0-54-generic/misc

(btw, this is on Ubuntu 12.04.3 LTS)

[craigwatson]

Thanks, can you confirm that it's vmci.ko and not vmci.o? The discrepancy could be causing the exec to run.

Also, can you confirm the values of the following facts:

• vmwaretools_version
• esx_version
• kernelrelease

[ventz]

It's only vmci.o (dot O). This is the case on almost all of the servers I tested with

I found one server where the misc dir is empty, and one where the misc dir is not even present.

From the facts:

facter | grep -i 'kernelrelease' kernelrelease => 3.2.0-54-generic

(the other one on some of the servers: kernelrelease => 3.2.0-55-generic)

The vmwaretools_version and esx_version are not present

I can tell you that these are running on esxi 5.0, using VMwareTools-8.6.0-446312.tar.gz vmware tools.

[craigwatson]

Thanks - the vmci.o is what's causing the config to re-run. Just to note, you'll need to run facter -p to pull in facts synchronised with Puppet - can you re-check these facts?

Strange though that vmware-config-tools.pl is reporting success but the kernel modules aren't being created/loaded, I have no such problems on my vSphere 5.5 test system (also using Ubuntu 12.04.3, but the virtual kernel rather than the generic one).

Can you also run which vmware-toolbox-cmd to check if the installation has actually gone through? Is the vSphere host reporting that the tools are installed correctly? A last-ditch attempt would be to run vmware-config-tools.pl -d by hand and see what fails (VMware may have changed some of their default options)?

For reference, this is the contents of my /lib/modules/3.2.0-54-virtual/misc directory:

root@www-01:/lib/modules/3.2.0-54-virtual/misc# ls -l
total 272
-rw-r--r-- 1 root root 155376 Oct  9 13:08 vmci.ko
-rw-r--r-- 1 root root  35989 Oct  9 13:08 vmxnet.ko
-rw-r--r-- 1 root root  83093 Oct  9 13:08 vsock.ko

[ventz]

Thanks for pointing that out about facter.

esx_version => 5 vmwaretools_version => 8.6.0-446312

VMware toolbox cmd: /usr/bin/vmware-toolbox-cmd

Yes - the vmware host is reporting the tools as installed and running

I'll send as an email the long paste with the errors from "vmware-config-tools.pl -d "

[craigwatson]

Hi,

Are you still experiencing the issue? I'm still trying to come up with a fool-proof way of running the vmware-config-tools.pl exec, it's proving a tricky thing to nail down! I'll close the issue for the moment as I can't seem to reproduce it reliably, but please feel free to re-open if it's still an issue for you.

Thanks, Craig