Using a RHEL7 based system, and the latest tigervnc install, together with the latest Anaconda package direct from the Anaconda site.
Prior to Anaconda, tigervnc had no issue starting up multiple services. Post Anaconda install, in order to have the python path set to use Anaconda, in .bashrc the file was edited to include to specifics to check to see if python was set to be anaconda. In the check, if it hasn't, the export path="/blahpath/anaconda2/bin:$PATH" entry is present and sets it. This works for anaconda, but if that piece is enabled, then when the vncserver services I have setup to start, fail to do so.
The error message in the vnc server logs are as follows:
dbus_proxy_call_internal: assertion `G_IS_DBUS_PROXY (proxy)' failed
It appears that there is some sort of dbus conflict going on, as when I comment out the anaconda export path entry in .bashrc, everything starts up just fine.
For vncserver in the .vnc director for the user everything binds against (which is where the .bashrc file lives for that user to be able to access their desktops via vnc), everything is set correctly as far as I can tell by default:
[code]
#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
/etc/X11/xinit/xinitrc
vncserver -kill $DISPLAY
[/code]
I'd rather not have to have the user set their python path manually each time they vnc over to their box. I for the life of me cannot find a solution to this. I see plenty of other similar posts about the same topic, some stating they've solved the issue, but 0 details on how.
It seems like there should be a way to work around the dbus proxy by setting an additional parameter somewhere, but I cannot figure out what and where.
Any assistance here would be greatly appreciated!
ln -s /usr/bin/gdbus gdbus
ln -s /usr/bin/dbus-daemon dbus
ln -s /usr/bin/dbus-binding-tool dbus-binding-tool
ln -s /usr/bin/dbus-cleanup-sockets dbus-cleanup-sockets
ln -s /usr/bin/dbus-daemon dbus-daemon
ln -s /usr/bin/dbus-launch dbus-launch
ln -s /usr/bin/dbus-monitor dbus-monitor
ln -s /usr/bin/dbus-run-session dbus-run-session
ln -s /usr/bin/dbus-send dbus-send
ln -s /usr/bin/dbus-test-tool dbus-test-tool
ln -s /usr/bin/dbus-update-activation-environment dbus-update-activation-environment
ln -s /usr/bin/dbus-uuidgen dbus-uuidgen
Of course, the location of each item may vary on your system, so do a :
which whatever
that will give you the location of said item if it indeed exists.
Did that, uncommented the export line in the .bashrc file and everything appears to be happy between anaconda2 and tigervnc.
Now, for the anaconda devs, somehow, someway, this is what YOU need to do in your code. You should be finding the default defacto versions of gdbus and what have you that you are attempting to call and call those, so that this sort of thing does not happen.
My two cents anyways, plus inflation.