LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Desktop (http://www.linuxquestions.org/questions/linux-desktop-74/)
-   -   Admin GUI Tools can't see X when used via RDP. F20 in a VM, Mate Desktop (http://www.linuxquestions.org/questions/linux-desktop-74/admin-gui-tools-cant-see-x-when-used-via-rdp-f20-in-a-vm-mate-desktop-4175498874/)

sbungay 03-20-2014 11:33 AM

Admin GUI Tools can't see X when used via RDP. F20 in a VM, Mate Desktop
 
Before anyone suggests the obvious, yes the command line still works, but using the CLI does not fix the underlying issue. What is described here may be an early warning of difficulties yet to come when spinning up desktop Linux in Virtual machines.

When trying to perform ANY admin task using a GUI tool (eg. system-config-services, system-config-users) complains that "system-config-"[insert your tool name here]" requires a currently running X server."

"RuntimeError: 'could not open display'

Now when one uses VNC to get into the box it all works wonderfully, but for various reasons which I will not go into here VNC is not an option. So, the question I pose is;

"Why do the GUI Admin tools in F20 think that the XServer is not running?

The contents of xrdp-sesman.log

[20140320-12:00:53] [WARN ] [init:45] libscp initialized
[20140320-12:00:53] [CORE ] starting sesman with pid 563
[20140320-12:00:53] [INFO ] listening...
[20140320-12:04:25] [INFO ] scp thread on sck 7 started successfully
[20140320-12:04:26] [INFO ] ++ created session (access granted): username [redacted], ip [IP ADDR REDACTED]:45761 - socket: 7
[20140320-12:04:26] [INFO ] starting Xvnc session...
[20140320-12:04:26] [INFO ] starting xrdp-sessvc - xpid=1116 - wmpid=1115

This appears to indicate that everything is OK, yet ALL of the GUI Admin tools fail to see the X server, the big question is "Why"?

More info.
When tail(ing) /var/log/messages we see the following;

Mar 20 12:43:14 localhost dbus-daemon: follow_name_owner_changes=follow_name_owner_changes)
Mar 20 12:43:14 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 248, in __init__
Mar 20 12:43:14 localhost dbus-daemon: self._named_service = conn.activate_name_owner(bus_name)
Mar 20 12:43:14 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 175, in activate_name_owner
Mar 20 12:43:14 localhost dbus-daemon: return self.get_name_owner(bus_name)
Mar 20 12:43:14 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 361, in get_name_owner
Mar 20 12:43:14 localhost dbus-daemon: 's', (bus_name,), **keywords)
Mar 20 12:43:14 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
Mar 20 12:43:14 localhost dbus-daemon: message, timeout)
Mar 20 12:43:14 localhost dbus-daemon: DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Mar 20 12:43:39 localhost dbus-daemon: ERROR:dbus.connection:Exception in handler for D-Bus signal:
Mar 20 12:43:39 localhost dbus-daemon: Traceback (most recent call last):
Mar 20 12:43:39 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 230, in maybe_handle_message
Mar 20 12:43:39 localhost dbus-daemon: self._handler(*args, **kwargs)
Mar 20 12:43:39 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/scservices/core/systemd/manager.py", line 101, in on_unit_new
Mar 20 12:43:39 localhost dbus-daemon: new_unit = SystemDUnit(self, unit_id, unit_path)
Mar 20 12:43:39 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/scservices/core/systemd/unit.py", line 102, in __init__
Mar 20 12:43:39 localhost dbus-daemon: self.bus_path)
Mar 20 12:43:39 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 241, in get_object
Mar 20 12:43:39 localhost dbus-daemon: follow_name_owner_changes=follow_name_owner_changes)
Mar 20 12:43:39 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 248, in __init__
Mar 20 12:43:39 localhost dbus-daemon: self._named_service = conn.activate_name_owner(bus_name)
Mar 20 12:43:39 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 175, in activate_name_owner
Mar 20 12:43:39 localhost dbus-daemon: return self.get_name_owner(bus_name)
Mar 20 12:43:39 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 361, in get_name_owner
Mar 20 12:43:39 localhost dbus-daemon: 's', (bus_name,), **keywords)
Mar 20 12:43:39 localhost dbus-daemon: File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
Mar 20 12:43:39 localhost dbus-daemon: message, timeout)
Mar 20 12:43:39 localhost dbus-daemon: DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.


What piqued my interest was the bit about the message bus security policy possibly blocking the reply. Am investigating further...


All times are GMT -5. The time now is 12:10 PM.