Red Hat Bugzilla – Bug 209452
Gedit can't handle multiple logins from same user
Last modified: 2013-04-15 04:46:07 EDT
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: Always 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.
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 inclusion.
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?
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. -Sam
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. ***
devack.
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
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 complaints. Want me to cook something up?
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 :-)
See totem_display_is_local(): http://svn.gnome.org/viewvc/totem/trunk/src/backend/video-utils.c?view=markup 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 DISPLAY=localhost:[0-9] 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. http://rhn.redhat.com/errata/RHBA-2008-0019.html