terminates python with "cannot connect to X server"

[Martin Pool]

On Natty, with $DISPLAY not set, and running under ssh and screen:

[3] mbp@grace% python
Python 2.7.1+ (r271:86832, Mar 24 2011, 00:37:39)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from launchpadlib.launchpad import Launchpad
>>> lp = Launchpad.login_with('butter')
: cannot connect to X server
[3] mbp@grace%

I was expecting it to either start w3m or lynx, or to print a url I could open on another machine.

Notice also that it seems to have abruptly terminated Python. I see the same thing within hydrazine. That's a bit evil.

[Martin Pool (mbp)]

ok, strace seems to show that this is coming from within pyqt4 trying to connect to its keyring. istr we saw something similar previously, maybe in bzr?

[Martin Pool (mbp)]

With python-qt4 removed, I get a python traceback from gnome keyring.

I'm pretty sure this is a new regression in natty.

I think lplib needs to guard against the keyring methods failing.

[Curtis Hovey (sinzui)]

I think this issue is complex. The authentication rules were changes to use the keyrings to work as desktop users expect them to. I think the server story was forgotten. Since the GUI tools cannot be expected to exist, I believe new rules are needed to get the auth token for servers. I am tagging this as a regression, though I may be wrong.

[Martin Pool (mbp)]

Hi Curtis,

I agree this is a regression and fairly bad for servers.

I would incline towards just amputating it by simply not using the
keyring module unless $DISPLAY is set: go back to getting the token
from a dot file. That is similar to what was done in previous
releases, and I don't think server or text-mode users would want us to
do otherwise, and it is probably easier than trying to persuade
python's keyring module not to try to connect to dbus etc. It may fix
some other bugs at the same time.

[Benji York (benji)]

I haven't seen this particular behavior before. Similar server (i.e.,
non-desktop) scenarios were brought up in bug 686690 and addressed in
launchpadlib 1.9.0 and later.

The keyring library has difficulties with keyring/wallet backends that
appear to be available but when used do not work. That seems to be the
class of defect being experienced here.

A version of Martin's suggestion is the best I can come up with at the
moment: Change keyringlib such that it will not consider the GNOME and
KDE backends to be available unless DISPLAY is set.

A temporary workaround would be to specify file-based token storage by
creating a ~/keyringrc.cfg file with these contents:

   [backend]
   default-keyring=keyring.backend.UncryptedFileKeyring

A tangential note: for non-interactive use (e.g., cron jobs) you should
use the credentials_file="/path/to/file" argument. In this case you'll
still get the same error unless you force a non-GUI keyring backend.

Once the credential file exists (and is valid), no further keyring
access will be attempted.

[Markus Korn (thekorn)]

For the GnomeKeyring backend I would rather check if "DBUS_SESSION_BUS_ADDRESS" is set, which means a session bus is running. Because if DISPLAY is set and DBUS_SESSION_BUS_ADDRESS is not gnomekeyring will fail. And some value in DBUS_SESSION_BUS_ADDRESS implies a non empty DISPLAY.

[Martin Pool (mbp)]

On 15 April 2011 01:18, Benji York <email address hidden> wrote:
> I haven't seen this particular behavior before.  Similar server (i.e.,
> non-desktop) scenarios were brought up in bug 686690 and addressed in
> launchpadlib 1.9.0 and later.

Well, they are addressed in the sense that there is a designed path
for them to work by using plain credential files. The problem is that
path does not work reliably in some common cases, like ssh-ing to a
machine with X forwarding, or running under schroot.

> The keyring library has difficulties with keyring/wallet backends that
> appear to be available but when used do not work.  That seems to be the
> class of defect being experienced here.

That's right. Really these are bugs in lower layers but my experience
with bzr-gtk suggests we will have to just work around them in lplib.

[Benji York (benji)]

On Thu, Apr 14, 2011 at 10:06 PM, Martin Pool <email address hidden> wrote:
>> The keyring library has difficulties with keyring/wallet backends that
>> appear to be available but when used do not work.  That seems to be the
>> class of defect being experienced here.
>
> That's right.  Really these are bugs in lower layers but my experience
> with bzr-gtk suggests we will have to just work around them in lplib.

Since I'm a contributor (more or less the only one at this point) to the
python keyring library, we should be able to push any workarounds down
at least that far.
--
Benji York

[Gary Poster (gary)]

I've made a fix in the python keyring.

https://bitbucket.org/kang/python-keyring-lib/pull-request/3/do-not-try-to-connect-to-the-gnome-keyring

I checked for DBUS_SESSION_BUS_ADDRESS, as Markus suggested, as well as DISPLAY. Benji did a bit of experimentation to show that it was possible to have the DBUS_SESSION_BUS_ADDRESS but not DISPLAY, and we believe that it is correct in that case to not try to work with the Gnome keyring.

[Gary Poster (gary)]

Code has been merged into trunk

I plan to close this bug when Oneiric has the fix.

[Gary Poster (gary)]

Benji made a release of the python-keyring code on PyPI. I have contacted the Debian packager asking him to include in Debian.

[Gary Poster (gary)]

This is now in Sid. I'm trying to find out what I need to do to get this in Oneiric now.

[Gary Poster (gary)]

Oneiric: bug 822844

[Gary Poster (gary)]

Released in Oneiric. Note that this fix is for Gnome.