I have the same problem. Can xfce4-session not be run independently on two different X displays?
It seems to be necessary to run xfce4-session in the VNC xstartup file, since simply running xfwm4 there will not give me e.g. any mouse menu in the VNC root window. But it doesn't work due to this error.
start a VNC desktop with 'startxcfe4' in your ~/.vnc/xstartup
log into the VNC session and admire the blank screen
There's 1 very crude workaround I know of and that's starting the VNC session before starting a XFCE4 session on the console.
I found this while googling around for a solution:
commit b0eec65b
Author: Benedikt Meurer benny@xfce.org
Date: Thu Dec 11 17:09:25 2003 +0000
Added check to see if another session is already running.
Dog only knows why Benny thought it was a good idea to allow only 1 XFCE4 session running. But for some reason or another an XFCE4 session running inside VNC is not detected.
Can someone PLEASE have a look at this, or point me to a practical workaround. Fooling around with xfwm4 and xfce4-panel in my .vnc/xstartup file didn't work. xfce4-panel also complains about 'There is already a running instance'.
For me this is a real showstopper for rolling out XFCE4 as the default desktop in our department.
In addition, I found a nice workaround, which was to strip the enviromnent
in ~/.vnc/xstartup before calling xfce4-session. The code in this the
above-mentioned change suggested it would be enough to strip SESSION_MANAGER,
but this did not prove to be enough, so I stripped everything apart from what I
knew I needed. This gave me the following xstartup script, which worked for me:
Following up on Alexis' workaround, it is sufficient to undefine SESSION_MANAGER and DBUS_SESSION_BUS_ADDRESS. This does not need to be done in xstartup, but can be done when starting the vnc session:
env -u SESSION_MANAGER -u DBUS_SESSION_BUS_ADDRESS vncserver
which leaves xsession alone.
One could also edit the vncserver script and fandango on %ENV before the system call, which might be easier than editing every user's .xsession.
My workaround is to unset DBUS_SESSION_BUS_ADDRESS at the beginning of /etc/lightdm/Xsession, however, the unneeded dbus-daemon started by its parent remains