Bug 209452
| Summary: | Gedit can't handle multiple logins from same user | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Sam Knuth <sfolkwil> | ||||
| Component: | gedit | Assignee: | Ray Strode [halfline] <rstrode> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.0 | CC: | bnocera, rstrode | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | RHBA-2008-0019 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-01-16 14:12:13 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Sam Knuth
2006-10-05 13:35:35 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.
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 |