Bug 1031665 - Cannot start vino on the remote server
Cannot start vino on the remote server
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: vino (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Søren Sandmann Pedersen
Desktop QE
: TestBlocker, Triaged
Depends On:
  Show dependency treegraph
Reported: 2013-11-18 08:43 EST by Matěj Cepl
Modified: 2014-09-01 16:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-21 19:00:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/Xorg.1.log (8.37 KB, text/plain)
2013-11-18 11:24 EST, Matěj Cepl
no flags Details
all /var/log/Xorg* and /var/log/gdm logs (71.02 KB, application/zip)
2013-11-18 11:26 EST, Matěj Cepl
no flags Details

  None (edit)
Description Matěj Cepl 2013-11-18 08:43:47 EST
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://
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://
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://
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):

How reproducible:
happened once (cannot reproduce)

Steps to Reproduce:
1.see above

Actual results:
no connection

Expected results:
connection from vinagre

Additional info:
Comment 2 Matěj Cepl 2013-11-18 11:24:03 EST
So aside from missing installation of group "X Window System" we have a bug somewhere in Xorg. See attached Xorg logs.
Comment 3 Matěj Cepl 2013-11-18 11:24:39 EST
Created attachment 825735 [details]
Comment 4 Matěj Cepl 2013-11-18 11:26:29 EST
Created attachment 825736 [details]
all /var/log/Xorg* and /var/log/gdm logs
Comment 5 Matěj Cepl 2013-11-18 11:29:31 EST

[root@localhost ~]# rpm -qa xorg\*
[root@localhost ~]#
Comment 7 Adam Jackson 2013-11-21 12:28:23 EST
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.
Comment 8 Ray Strode [halfline] 2013-11-21 14:46:57 EST
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.
Comment 9 Ray Strode [halfline] 2013-11-21 19:00:38 EST
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.

Note You need to log in before you can comment on or make changes to this bug.