Bug 209452 - Gedit can't handle multiple logins from same user
Summary: Gedit can't handle multiple logins from same user
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gedit
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Ray Strode [halfline]
QA Contact:
Keywords: Reopened
: 246261 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2006-10-05 13:35 UTC by Sam Knuth
Modified: 2013-04-15 08:46 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2008-01-16 14:12:13 UTC

Attachments (Terms of Use)
strace of gedit crash (2.44 MB, text/plain)
2006-10-05 13:38 UTC, Sam Knuth
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0019 normal SHIPPED_LIVE gedit bug fix update 2008-01-16 14:12:11 UTC

Description Sam Knuth 2006-10-05 13:35:35 UTC
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

How reproducible:

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
Actual results:
* 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.

Expected results:
* Gedit says up on the local machine
* Gedit open on the remote machine

Additional info:

I don't think this is limited to GEDIT - I believe it's a general gnome/gconf issue.

Comment 1 Sam Knuth 2006-10-05 13:38:16 UTC
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.

Comment 2 Ray Strode [halfline] 2006-10-05 17:20:58 UTC
what makes you think this isn't a gedit specific issue?

Comment 3 Sam Knuth 2006-10-05 19:27:44 UTC
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.

Comment 5 RHEL Product and Program Management 2006-11-14 20:21:06 UTC
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

Comment 6 Ray Strode [halfline] 2006-12-06 16:12:38 UTC
Hi Sam,

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?

Comment 7 Sam Knuth 2006-12-14 17:31:10 UTC
Hi Ray,

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.


Comment 8 RHEL Product and Program Management 2007-06-05 20:51:57 UTC
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.

Comment 11 Ray Strode [halfline] 2007-11-12 20:52:48 UTC
*** Bug 246261 has been marked as a duplicate of this bug. ***

Comment 12 Ray Strode [halfline] 2007-11-13 20:10:06 UTC

Comment 14 Ray Strode [halfline] 2007-12-18 21:39:14 UTC
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
(auth cookie)

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
fairly uninvasive.

Should be fixed in gedit-2.16.0-7.el5

Marking MODIFIED for QA

Comment 15 Bastien Nocera 2007-12-18 21:58:02 UTC
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?

Comment 16 Ray Strode [halfline] 2007-12-18 22:15:46 UTC
if you have tested code that's less hacky than the 

if (getenv("DISPLAY")[0] != ':') return FALSE;

equivalent I have now, I'd love it if you'd cook something up :-)

Comment 17 Bastien Nocera 2007-12-18 22:47:20 UTC
See totem_display_is_local():

And just return NULL in bacon_message_connection_new() if display isn't local.

Comment 18 Ray Strode [halfline] 2007-12-19 14:37:50 UTC
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.

Comment 22 errata-xmlrpc 2008-01-16 14:12:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.