Hello, On Sun, Oct 04, 2009 at 11:50:34PM +0300, Vasilis Pappas wrote in bug #545222:
> I had the same problem and I think I found a workaround.. > The problem seems to be that vmtoolsd is trying to load .so plugins but the > plugin-path that is given to it contains other directories. So, it simply > skips them and does not load any plugins (one of he plugins does the time > synchronization) > So, try the following : > cd /etc/vmware/plugins > cp vmusr/* vmsvc/* . > /etc/init.d/open-vm-tools restart I believe this fix to the cause of bug #564069: Putting all plugins together into one plugin directory causes vmtoolsd to load plugins that require a running X server. Because this is most likely not the case at boot time, it will bail immediately. In consequence time synchronisation and all other services provided by vmtoolsd will not work and VMware will complain about VMtools not running on the guest. The only indicator is a warning message when called with the --log option *without* a running X server: # vmtoolsd --plugin-path=/etc/vmware-tools/plugins --log [Jan 20 22:55:55.819: ] [ warning] [Gtk] cannot open display: I believe the proper solution to both bugs is as follows: - leave the plugins in their subdirectories vmsvc and vmusr as installed by the Makefile - remove option --plugin-path /etc/vmware-tools/plugins from /etc/init.d/open-vm-tools This will cause vmtoolsd to find its plugins in /usr/local/open-vm-tools/vmsvc automagically. The symlink /etc/vmware-tools/plugins can be removed. With these changes applied, vmtoolsd starts and runs normally on my system now. -- Thanks in advance, Micha -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
