#34 Cannot connect to display

[Guido Berhoerster]

I seem to encounter a problem very similar to that in bug #1623900, that is instantiating Xlib.display.Display results in the following traceback every time:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/site-packages/Xlib/display.py", line 85, in __init__
self.display = _BaseDisplay(display)
File "/usr/lib/python2.6/site-packages/Xlib/display.py", line 67, in __init__
apply(protocol.display.Display.__init__, (self, ) + args, keys)
File "/usr/lib/python2.6/site-packages/Xlib/protocol/display.py", line 121, in __init__
raise error.DisplayConnectionError(self.display_name, r.reason)
Xlib.error.DisplayConnectionError: Can't connect to display ":0.0": No protocol specified

However, this is with Python 2.6.5 and python-xlib 0.14 which contains the fix for bug #1623900.

[Guido Berhoerster]

I've looked into this issue, the problem here is that the xauthority file parsing code assumes that there is an entry for the hostname returned by gethostname(). If the entries' address is different, e.g. "localhost" in my
case, it wont find the cookie and will subsequently fail to connect.

Fixing this in case of "localhost" would be easy, it could be added as a fallback if we have a Unix socket. However, this is not sufficient as entriescould be set to something else such as an alias hostname.
What would be the best way to handle this more generically?

There is also the old_get_auth function which parses the "xauth list" ouput. However it is hardcoded to always take the cookie from the first line of output, is that guaranteed to be the right one?

[Mike Grant]

So, if I understand you correctly, there is no host specified (e.g. $DISPLAY = :0.0) so the code looks up the local hostname of the machine and gets "your.machine.domain". However, the X cookie is stored under another hostname (in your case "localhost").

It would be interesting to know how the X server got one hostname but python is getting another - perhaps the hostname is set when you connect to your network, after X has started up?

I'm also unsure of the best way around this - one obvious option is to ensure the hostname doesn't change (seems to have caused problems in other contexts, e.g. http://www.macosxhints.com/article.php?story=20040426134835245\), but that's not necessarily going to work in the real world ;)

Perhaps one way would be to convert domain names in the .Xauthority file back to IPs and compare those? This also sounds a bit unsafe.

Another thought is that this will presumably only occur for unix sockets - perhaps we could ignore the hostname field in this case as it's not meaningful and just use family (unix) and display number. This assumes there's only one cookie per display for unix sockets.

[Guido Berhoerster]

> It would be interesting to know how the X server got one hostname but
> python is getting another - perhaps the hostname is set when you connect to
> your network, after X has started up?

This is on Linux, GDM seems to set it to "localhost".

> Perhaps one way would be to convert domain names in the .Xauthority file
> back to IPs and compare those? This also sounds a bit unsafe.

In any case you would need to determine all IP addresses of the local host, then you can also easily get all hostnames and aliases. Porbably non-trivial to implement in a cross-platform manner in Python.

> Another thought is that this will presumably only occur for unix sockets -
> perhaps we could ignore the hostname field in this case as it's not
> meaningful and just use family (unix) and display number. This assumes
> there's only one cookie per display for unix sockets.

That also came to my mind, are the display number and a local socket sufficient? If there are several cookies for the current display number and a local socket, should we simply try them until one works? Not exactly clean either...

[Guido Berhoerster]

This problem is openSUSE-specific, after tracing xcb code I've found the underlying cause. xdm/gdm use openSUSE-specific patches in order to set the hostname to "localhost" by default when creating a cookie and to set an environment variable XAUTHLOCALHOSTNAME to localhost as well. libxcb is then patched to take the
value of XAUTHLOCALHOSTNAME as a fallback in case it does not find a cookie matching the hostname returned by gethostname() when connecting to a Unix socket. This is intended to avoid the problem of changing hostnames.
The original packager of the openSUSE python-xlib package was probably not aware of that, I've now patched the package accordingly (for reference: https://bugzillafiles.novell.org/attachment.cgi?id=384080\). I don't know if it makes sens to include this here as this has not been upstreamed into Xlib/xcb.