Red Hat Bugzilla – Bug 1031665
Cannot start vino on the remote server
Last modified: 2014-09-01 16:41:43 EDT
Description of problem: I would like to test vinagre/vino connection with a remote server. When connecting through ssh -Y with the remote computer and I run [test@localhost ~]$ gsettings set org.gnome.Vino enabled true [test@localhost ~]$ /usr/libexec/vino-server ** (vino-server:27972): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-rdrnpkn0L7: Connection refused Gtk-Message: Failed to load module "pk-gtk-module" (vino-server:27972): EggSMClient-CRITICAL **: egg_sm_client_set_mode: assertion `global_client == NULL || global_client_mode == EGG_SM_CLIENT_MODE_DISABLED' failed 18/11/2013 08:31:21 Autoprobing TCP port in (all) network interface 18/11/2013 08:31:21 Listening IPv6://[::]:5900 18/11/2013 08:31:21 Listening IPv4://0.0.0.0:5900 18/11/2013 08:31:21 Autoprobing selected port 5900 18/11/2013 08:31:21 Advertising security type: 'TLS' (18) 18/11/2013 08:31:21 Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface 18/11/2013 08:31:21 Listening IPv6://[::]:5900 18/11/2013 08:31:21 Listening IPv4://0.0.0.0:5900 18/11/2013 08:31:21 Clearing securityTypes 18/11/2013 08:31:21 Advertising security type: 'TLS' (18) 18/11/2013 08:31:21 Clearing securityTypes 18/11/2013 08:31:21 Advertising security type: 'TLS' (18) 18/11/2013 08:31:21 Advertising authentication type: 'No Authentication' (1) 18/11/2013 08:31:26 Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface 18/11/2013 08:31:26 Listening IPv6://[::]:5900 18/11/2013 08:31:26 Listening IPv4://0.0.0.0:5900 18/11/2013 08:31:49 [IPv4] Got connection from client ovpn-116-81.ams2.redhat.com 18/11/2013 08:31:49 other clients: (vino-server:27972): Gdk-ERROR **: The program 'vino-server' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAccess (attempt to access private resource denied)'. (Details: serial 194 error_code 10 request_code 130 minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trace/breakpoint trap [test@localhost ~]$ journalctl -e shows a line Nov 18 08:31:50 localhost.localdomain kernel: traps: vino-server[27972] trap int3 ip:7fd459579e0d sp:7ffff096fb10 error:0 Version-Release number of selected component (if applicable): vino-3.8.1-3.el7.x86_64 How reproducible: happened once (cannot reproduce) Steps to Reproduce: 1.see above 2. 3. Actual results: no connection Expected results: connection from vinagre Additional info:
So aside from missing installation of group "X Window System" we have a bug somewhere in Xorg. See attached Xorg logs.
Created attachment 825735 [details] /var/log/Xorg.1.log
Created attachment 825736 [details] all /var/log/Xorg* and /var/log/gdm logs
Installed: [root@localhost ~]# rpm -qa xorg\* xorg-x11-drv-qxl-0.1.1-5.el7.x86_64 xorg-x11-drv-nouveau-1.0.10-3.el7.x86_64 xorg-x11-glamor-0.5.1-3.20131023git16c86bd.el7.x86_64 xorg-x11-drv-wacom-0.23.0-3.el7.x86_64 xorg-x11-font-utils-7.5-17.el7.x86_64 xorg-x11-xinit-1.3.2-8.el7.x86_64 xorg-x11-drv-ati-7.2.0-6.20131023gitf1dc677.el7.x86_64 xorg-x11-drv-evdev-2.8.2-3.el7.x86_64 xorg-x11-drv-vmmouse-13.0.0-8.el7.x86_64 xorg-x11-drv-vmware-13.0.1-5.el7.x86_64 xorg-x11-drivers-7.7-5.el7.x86_64 xorg-x11-xauth-1.0.7-3.el7.x86_64 xorg-x11-server-utils-7.7-2.el7.x86_64 xorg-x11-xkb-utils-7.7-8.el7.x86_64 xorg-x11-server-common-1.14.99.901-5.20131101.el7.x86_64 xorg-x11-drv-vesa-2.3.2-12.el7.x86_64 xorg-x11-drv-fbdev-0.4.3-12.el7.x86_64 xorg-x11-drv-modesetting-0.8.0-6.el7.x86_64 xorg-x11-drv-synaptics-1.7.1-7.el7.x86_64 xorg-x11-drv-intel-2.21.15-9.el7.x86_64 xorg-x11-server-Xorg-1.14.99.901-5.20131101.el7.x86_64 xorg-x11-drv-v4l-0.2.0-33.el7.x86_64 xorg-x11-drv-dummy-0.3.6-13.el7.x86_64 xorg-x11-drv-void-1.4.0-21.el7.x86_64 xorg-x11-utils-7.5-9.el7.x86_64 [root@localhost ~]#
Attachment 825735 [details] shows X failing to start when we have fbdev but not modesetting installed, which is unfortunate. But it can't be the cause of vino not working, because comment #0 shows the vino server starting and then crashing, which means X _has_ to be running - and indeed, Xorg.0.log from attachment 825736 [details] shows X running. Assuming nothing special about the guest, major opcode 130 typically means MIT-SHM in current RHEL7, and minor code 5 for that is the ShmCreatePixmap request. There's a couple of ways that could throw BadAccess: - if the X server doesn't have write permission to the shm segment but the request asked for it - if the size+offset in the request extends beyond the end of the shm segment - if XACE security policy prevents it We can probably exclude the third option since we don't have an XACE policy by default. My hunch is that it's the second one, since this setup is using the cirrus device, which can only do 24bpp not 32bpp, so it's likely that vino is miscomputing the shm segment size. (If permissions were wrong vino just wouldn't work at all on any device, so that seems unlikely.) Reassigning to vino on that basis. Matěj, can reproduce this problem on other guest video devices (vga, qxl, or vmware)? If you can't then this probably shouldn't be considered a test blocker.
FWIW, I don't think you want to run vino-server from a connect that has X11 forwarding enabled with ssh -Y. If you do that, you really need to set DISPLAY to the session you're trying to share. when you ssh -Y, DISPLAY is going to be set to the DISPLAY you're sshing *from*, which you almost certainly don't want to do. Furthermore, i don't think SHM works over SSH tunneled X, so that's probably why it's failing.
Chatted with Matej abou this. He didn't mean to use ssh -Y and there were some other missing bits in his installation. I'm going to go ahead and close this out, since I don't think the cosmetic problems are worth prioritizing time for.