Description of problem: vncserver session cannot be used and gnonme desktop does not start. Message on screen says "could not acquire name on session bus". running vncserver on an F11 x86_64 KVM guest and connecting to it with vncviewer on F10 x86_64. firewall is disabled and user is able login as evidenced by screen shot. Version-Release number of selected component (if applicable): [root@localhost ~]# rpm -qa | grep tiger tigervnc-server-module-0.0.90-0.5.20090403svn3751.fc11.x86_64 tigervnc-0.0.90-0.5.20090403svn3751.fc11.x86_64 tigervnc-server-0.0.90-0.5.20090403svn3751.fc11.x86_64 How reproducible: 100% Steps to Reproduce: 1. vncserver :3 2. vncviewer hostname:3 3.
Created attachment 341254 [details] screen shot of broken session
Created attachment 341255 [details] vnc log
John, can you confirm that starting the desktop on this KVM guest through virt-viewer works? Also, can you upload your /var/log/install.log file? Thanks!
Could you please attach your ~/.vnc/xstartup file, please?
Created attachment 341435 [details] Default ~/.vnc/xstartup (tigervnc-0.0.90-0.5.20090403svn3751.fc11.x86_64)
I moved away my entire ~/.vnc/ folder and started a vncserver. The process used the default, automatically provided ~/.vnc/xstartup (attached) and the bug occurs in that case.
(In reply to comment #3) > John, can you confirm that starting the desktop on this KVM guest through > virt-viewer works? Also, can you upload your /var/log/install.log file? > > Thanks! Yes desktop starts normal from virt-manager
problem still exits with [root@localhost ~]# rpm -qa | grep tiger tigervnc-0.0.90-0.7.20090427svn3789.fc11.x86_64 tigervnc-server-module-0.0.90-0.7.20090427svn3789.fc11.x86_64 tigervnc-server-0.0.90-0.7.20090427svn3789.fc11.x86_64
I'm still not able to reproduce this issue. Would it be possible to try reproduce this bug on fresh installation and then attach generated kickstart, please? (/root/anaconda-ks.cfg) Thanks
reproduced with fresh installation w/ today's rawhide will attach anaconda-ks.cfg 1) install guest 2) yum install tiger* 3) turn firewall off 4) as nonpriv user $ vncserver :3 --setup password for the first time 5) connect to guest:3 6) see error message bare metal system is x86_64 as is guest
Created attachment 343496 [details] anaconda ks file
Odd, I installed same machine via your kickstart and it works fine in my case. From Xvnc log it seems there is a problem with dbus. Please check if session dbus daemon is started. before vncserver: $ ps ax |grep dbus 1032 ? Ssl 0:00 dbus-daemon --system 1574 pts/0 S+ 0:00 grep dbus after vncserver: $ ps ax |grep dbus 1032 ? Ssl 0:00 dbus-daemon --system 1595 pts/0 S 0:00 dbus-launch --sh-syntax --exit-with-session 1596 ? Ssl 0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 1642 ? S 0:00 dbus-daemon --system 1670 pts/0 S+ 0:00 grep dbus Next problem might be SELinux - could you please verify if you have any related AVC denial in log?
Not sure what to tell you. I've reproduced this on a third system, this time i386 F11 box connecting from F10 x86_64 # ps ax |grep dbus 1424 ? Ssl 0:00 dbus-daemon --system 1822 ? S 0:00 /usr/bin/dbus-launch --exit-with-session 2049 ? S 0:00 dbus-launch --sh-syntax --exit-with-session 2050 ? Ssl 0:09 /bin/dbus-daemon --fork --print-pid 7 --print-address 9 --session 5110 pts/1 S+ 0:00 grep dbus There is nothing special I'm doing. 1) install new system with default package set 2) yum install tiger* 3) vncserver :3
After inspection it seems main problem is that GDM sets XAUTHORITY environment variable. When you run vncserver from GUI terminal and underlying X server was run via GDM you should hit this issue. This is also answer why I wasn't able to reproduce this bug - I always called vncserver from SSH based terminal (and because I'm not using GDM) thus XAUTHORITY variable wasn't set. I will attach proposed patch.
Created attachment 344135 [details] patch
Could you test if patch in comment #15 solves the problem, please? You can directly edit /usr/bin/vncserver. Thanks.
I applied the patch and tested, without restarting X or otherwise changing my environment. Now I simply get a blank screen without the GNOME session I'd expect. I'm attaching the .vnc/*log for that instance. The important part seems to be: Invalid MIT-MAGIC-COOKIE-1 keyvncconfig: unable to open display ":1" Invalid MIT-MAGIC-COOKIE-1 keyxrdb: Resource temporarily unavailable ...and several other errors complaining about the invalid cookie.
Created attachment 344198 [details] VNC log
From Paul's feedback looks like there is still a problem. Let me know (via email or IRC) if you want access to my box again.
Created attachment 344411 [details] Improved patch Could you retest improved patch, please? This patch modifies default ~/.vnc/xstartup file so make sure you change your existing xstartup appropriately. Thanks.
Success! Using tigervnc-server-0.0.90-0.7.20090427svn3789.fc11.x86_64, I first made sure I was not using the patch from comment #15, then tried this patch. The VNC server doesn't appear to honor my geometry selection, but I'll file that separately.
Thanks for feedback. Fixed in tigervnc-0.0.90-0.9.fc11.