Description of problem:
It seems that gnome applications can not handle multiple logins from the same
user. For example, if you have gedit opened on your local machine, and then ssh
-X into that machine from another machine and try to open gedit there, the local
instance of gedit crashes, and the remote instance wont start at all.
Version-Release number of selected component (if applicable):
RHEL 5 Beta 1
Steps to Reproduce:
* Open a GEDIT window on the local machine
* SSH into that machine from another machine with X forwarding
* Open GEDIT on the remote machine
* Gedit crashes on the local machine
* Gedit does not open on the remote machine
* This error appears on the SSH terminal on the remote machine:
[samfw@xander ~]$ gedit
X11 connection rejected because of wrong authentication.
* Gedit says up on the local machine
* Gedit open on the remote machine
I don't think this is limited to GEDIT - I believe it's a general gnome/gconf issue.
Created attachment 137818 [details]
strace of gedit crash
Attaching an strace of first gedit instance on the local machine. This instance
crashes when the second instance is opened on the same machine by the same user
via an ssh -X session.
what makes you think this isn't a gedit specific issue?
sorry - let's work this as a gedit issue for now. I have a theory that might be
a bit premature about other gnome applications, but I need more testing for that.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
I just noticed you said that you tried ssh -X. ssh -X isn't really that useful
of a command anymore. For the most part it's been superceded by ssh -Y (which
has the same semantics of ssh -X from RHEL4). If you try the sam experiment but
with ssh -Y, does it work better?
Sorry for the delay here. It doesn't make a difference if it's -Y or -X - the
exact same results happen. This is in RHEL 5 Beta 2 or FC6 GA with latest errata.
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release. Since this
bugzilla is in a component that is not approved for the current
release, it has been closed with resolution deferred. You may
reopen this bugzilla for consideration in the next release.
*** Bug 246261 has been marked as a duplicate of this bug. ***
So here's what happens:
1) the first gedit instance starts up in factory mode
2) the second gedit instance notices the first one is being a factory
3) it then tells the first instance, "you create the window instead of me" and exits
4) The first gedit instance tries to open the ssh display
5) it promptly fails because it doesn't know the displays generated password
Some of this factory handling code happens with in a set of convenience
functions called libbacon that gets cut-and-paste into various projects.
Bastien wrote libbacon, so I'm CCing him.
We have a few options:
a) fix libbacon to forward the auth cookie along to the server instance, and get
the server instance to add the auth cookie to its list of known cookies
b) change libbacon to have a new step between 3) and 4) above which makes the
server ack to the client "Okay, I'm able to do what you're asking of me" or nack
to the client "I tried to take over for you but couldn't"
c) disable the factory code entirely in the ssh forwarding case
both a) and b) are fairly invasive and require changing libbacon itself (which
we don't really want to fork just for gedit), so c) seems like the best option.
The factory doesn't really offer any advantages in this case anyway.
One gotcha is, how do we know gedit's being forwarded? I think ssh sets some
environment variables we could check, but another alternative is to see if
DISPLAY is setup to use a tcp address instead of socket address.
The latter is the approach I came up with. It's not a great fix, but it's
Should be fixed in gedit-2.16.0-7.el5
Marking MODIFIED for QA
c) is definitely the right option. I have some pretty horrible piece of code in
Totem to detect if we are on a local display or not, and I haven't heard any
Want me to cook something up?
if you have tested code that's less hacky than the
if (getenv("DISPLAY") != ':') return FALSE;
equivalent I have now, I'd love it if you'd cook something up :-)
And just return NULL in bacon_message_connection_new() if display isn't local.
Hmm, that's pretty close to what I already built. The main difference is your
code would let
continue to use the factory (which is fine). Still, the change probably isn't
worth a rebuild.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.