RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1031665 - Cannot start vino on the remote server
Summary: Cannot start vino on the remote server
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: vino
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Søren Sandmann Pedersen
QA Contact: Desktop QE
URL:
Whiteboard: [cat:modesetting]
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-18 13:43 UTC by Matěj Cepl
Modified: 2014-09-01 20:41 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-22 00:00:38 UTC
Target Upstream Version:
Embargoed:

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

Description Matěj Cepl 2013-11-18 13:43:47 UTC 
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:
Comment 2 Matěj Cepl 2013-11-18 16:24:03 UTC 
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 16:24:39 UTC 
Created attachment 825735 [details]
/var/log/Xorg.1.log
Comment 4 Matěj Cepl 2013-11-18 16:26:29 UTC 
Created attachment 825736 [details]
all /var/log/Xorg* and /var/log/gdm logs
Comment 5 Matěj Cepl 2013-11-18 16:29:31 UTC 
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 ~]#
Comment 7 Adam Jackson 2013-11-21 17:28:23 UTC 
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 19:46:57 UTC 
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-22 00:00:38 UTC 
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.