Closed Bug 246313 Opened 20 years ago Closed 1 year ago

Firefox does not start: getting "XDM authorization key matches an existing client" "cannot open display" error

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: marcus, Unassigned)

References

Details

(Whiteboard: [See comment 33 problem 1 for analysis, freedesktop bug for workaround])

Attachments

(1 file)

output of strace32 ./firefox-bin with the XDM failure (.bz2)
227.17 KB, application/octet-stream
Details
I installed the new Firefox 0.9RC release with the installer into ~/firefox When I cd into this directory and try to start Firefox with ./firefox& , I get this error: Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:7314): Gtk-WARNING **: cannot open display: [1]+ Exit 1 ./firefox What's wrong? Any other application works fine with my X-Display, including Firefox 0.8 and Thunderbird 0.6 (both where NOT running while I was trying to start Firefox 0.9RC). I can reproduce this always.
Severity: normal → major
Some additional information: The nightly builds of 20040602 and 20040613 work fine, only the 0.9RC build can't be started.
Component: General → Startup and Profile System
I have the same problem. What's different about this message is the complaint about the XDM authorization key (I think it should be put in the summary of this bug!): Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:24475): Gtk-WARNING **: cannot open display: I'm seeing it on SUSE 9.1 Professional, 64-bit edition, with FireFox 0.9 final (firefox-0.9-i686-linux-gtk2+xft.tar.gz). I've done the following steps to help isolate the problem: * Renamed my ~/.mozilla * Created a new user to run it as * Restarted X (including xdm) Nothing seems to fix it. I will attach an strace of a failing session here momentarily.
Looks like it reads ~/.Xauthority, and then something funky happens. Had to bzip2 the attachment to fit under the 300k limit.
How strange: I rebooted my SUSE 9.1 machine earlier today, and now it works. I wonder if there was a patch that was installed that needed a reboot to affect? For reference, I restarted X before with Ctrl-Alt-Backspace
I had a SUSE 9.1 user report the same problem to me today, though he was on a 32-bit machine. While he had just rebooted 3 hours ago, I told him to reboot again to see if it would fix the problem: and it did. How bizarre.
Ok, this is funny. After reboot and NOT starting Firefox 0.8 before starting Firefox 0.9RC or 0.9 this works. It seems to me that it (the bug) only happens if you try to start Firefox 0.9 after Firefox 0.8 was running before that; then you need to reboot. Guess what: My system is a Suse 9.1 (32bit Athlon XP, GeForce 4 MX) with all available patches installed. Looks to me we localized the problem. I am not shure if this is really a major bug, maybe I should set it back to normal (it is still a bug with a known workaround)
I also see it here on a 0.9 build. Specifically, it only happens when it tries to run the profile conversion wizard.The bug can be worked around by removing the XDM-AUTHORIZATION-1 entry for the display in xauth. My collegue who hit it suggests that XOpenDisplay generates a key based on the pid and timestamp. He thinks that firefox is forking to run the wizard, but not closing the previous X display connection before opening a new one for the wizard. Thus, it requires you to have a previous profile to convert, and may randomly not happen if on a slower machine, or just "lucky" (the timestamp changes between the too display open calls).
I see that you were suspecting suse9.1. We're running a Debian testing snapshot from a few months ago. GTK version running is debian pkg version 2.2.4-2. Running in an xdm environment (xdm package version 4.3.0-6). XFree86 same version. My firefox build is compiled from CVS tag FIREFOX_0_9_RELEASE, with default extensions (ie from configure, not browser/.../mozconfig)
I found the same problem with firefox 0.9. If start firefox as root, it works. But honestly:I could change back to windows and IE to open such security holes on my system.
I am also using firefox 0.9 on SuSE 9.1. When I initially installed firefox 0.9 it worked just fine -- for more than a week. Suddenly I now get the same "XDM authorization" message mentioned by others. I tried the suggestions mentioned by others (i.e. removing .mozilla and .phoenix; rebooting) etc. to no avail. I even created a brand new user and tried to run firefox as that user but get the same thing. Oddly enough, If I run as root it works! I have not made any changes (e.g. new or updated packages) that I am aware of since firefox was working OK. I moved back to 0.8 and that works.
I also got the same bug with Thunderbird 0.7
As I mentioned before, a collegue looked into it. He noticed firefox re-execed itself after adding XRE_IMPORT_PROFILES=1 to the environment. So, a suggested workaround until this bug is fixed is to run firefox as such: XRE_IMPORT_PROFILES=1 firefox & The firefox that forks appears to not close its X connection before re-execing, thus creating the error.
Firefox 0.9.1 seems to resolve the problem! I installedfirefox 0.9.1 on SuSE Linux 8.2 using tue tar.gz installer. Now it works as expected. And it's fast!
The bug still exists in 0.9.1 for us. Are you sure you had: 1) Removed your 0.9 profile (rm ~/.mozilla/firefox) 2) NOT removed some older profile for it to import (e.g. ~/.phoenix) ? Given that setting the XRE_IMPORT_PROFILE variable doesn't seem to have negative effects when the profile has already been imported, then I've set that on in our firefox launching script to workaround this problem for everyone on our system.
I didn't remove the 0.9 profile. I removed it later, rebooted the machine, started firefox 0.9.1, imported my firefox 0.8 profile. And firrefox still worked. In a next step I removed firefox 0.9.1 and the nwely created firefox profile and reinstalled it. And the problem exists again.
This bug should be fixed for firefox 1.0. It doesn't happen always because it's some timing issue but the misbehaviour is definitely here because of the pref-migrator.
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-
As I think this a real bug. Can someone who decided that this doesn't block a 1.0PR version make a comment on that?
I am seeing this bug on an absolutely brand new system install (debian-amd64 experimental). I'm upping the severity to critical due to the number of people seeing this (on google searches) and the fact it renders the browser unusable unless you do the `xhost +; firefox&; xhost -` kludge that's floating around.
Severity: major → critical
As an additional note, this is related to Bug 224966 which is the exact same thing, but for Thunderbird. The two bugs might want to be joined together?
The workaround with XRE_IMPORT_PROFILES=1 works for me. This is the firefox version from debian-testing, I wanted to try it today. Firefox 0.9.3 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040917 Firefox/0.9.3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii mozilla-firefo 0.9.3-5 lightweight web browser based on Mozilla
I believe this has been fixed in 1.0-RC1 as I am no longer seeing this. Can other people who were see this test?
Firefox 1.0 on SuSE professional 8.2 still has this problem. I had some ugly crashes when opening some urls. So I decided to cerate a completley new environment by moving all .phoenix and .mozilla folders away. When I installed firefox 1.0 and started it as root. Everything was OK. Then I started firefox again as my normal user. After several atempts it really started to work. Here's the log from myconsole window: teffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:4086): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:4105): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:4124): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:4143): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:4162): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:4181): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:4200): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox *** nsExtensionManager::_disableObsoleteExtensions - failure, catching exception so finalize window can close *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application directory, skipping. *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application directory, skipping.
*** Bug 268588 has been marked as a duplicate of this bug. ***
(In reply to comment #22) I have still the same pb with debian sarge with firefox 1.0
(In reply to comment #24) > (In reply to comment #22) > I have still the same pb with debian sarge with firefox 1.0 I am getting this problem with firefox 1.0 under Suse Linux 9.0. It seems to work fine when I log in as root, but when I log in as myself I get the Xlib error.
I downloade and installed the 20041208 nightly release under SuSE Linux Professional 8.2, renamed my old .mozilla directory and started mozilla. No surprise. I had to repeat the command several times: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:3766): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:3785): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:3804): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:3823): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:3842): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:3861): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:3880): Gtk-WARNING **: cannot open display: steffu@steffux2:~> /opt/firefox/firefox *** nsExtensionManager::_disableObsoleteExtensions - failure, catching exception so finalize window can close *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application directory, skipping. *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application directory, skipping. And finally firefox runs. The story is getting boring. No news? No actions? Come on, this remembers much to M$
This bug is still alive and well on Debian sarge, package mozilla-firefox 1.0-4. Starting firefox for the first time with no .mozilla directory or existing profiles usually dies with the XDM message. The "xhost + ; firefox ; xhost -" hack works. Deleting all of /usr/lib/mozilla (only firefox is installed) and purging the last traces of the Mozilla browser does not always work. Adding XRE_IMPORT_PROFILES=1 to the firefox script does not always work. I say "does not always work" since the bug seems to be nondeterministic. Sometimes firefox starts up fine, other times it doesn't. This is a serious problem for us, since none of the students receiving new accounts for the spring semester will be able to run a web browser.
Today I tested the January 31 Build on SuSE 8.2 professional. It seems to work much better: I created a new user and thestarted mozilla 1.7.5 and then firefox while mozilla was still running: dummy@steffux2:~> /opt/mozilla/mozilla& [1] 8631 dummy@steffux2:~> /opt/firefox/firefox& [2] 8647 dummy@steffux2:~> Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:8665): Gtk-WARNING **: cannot open display: [2]+ Exit 1 /opt/firefox/firefox So far we know the problem. Strating firefox again (mozilla still running) worked with some error messages: dummy@steffux2:~> /opt/firefox/firefox& [2] 8670 dummy@steffux2:~> *** nsExtensionManager::_disableObsoleteExtensions - failure, catching exception so finalize window can close *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application directory, skipping. *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application directory, skipping. [1]- Done /opt/mozilla/mozilla [2]+ Done /opt/firefox/firefox cleaning up the .mozilla directory and starting firefox worked without problems: dummy@steffux2:~> rm -R .mozilla/ [3]+ Done /opt/firefox/firefox dummy@steffux2:~> /opt/firefox/firefox& [1] 8868 dummy@steffux2:~> *** nsExtensionManager::_disableObsoleteExtensions - failure, catching exception so finalize window can close *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application directory, skipping. *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application directory, skipping.
My joy was to early, from time to time firefox needs 3 or more attempts to start with no ~/.mozilla directory. Sometimes it works with the first attempt. could there be a kind aof random seed which is used to create the XDM authorization key? Could it be that this random seed is not properly initialized?
I had a similar problem installing firefox on Debian/Linux kernel 2.6.8. The problem occurred when I ran firefox for the first time as root, and also for the first time I ran it as a regular user. I expect it would happen for each user the first time firefox is run. A workaround is to do "xhost +" before running firefox the first time, which lets it run although it complains about some stuff. Then exit, do "xhost -", and run it again. Everything seems fine. Here is the log from the xterm window when I started it as a regular user. Sorry that the end of a few lines are clipped, the xterm wasn't wide enough to catch them. ====================================================== bill@home:~$ firefox & [1] 11648 bill@home:~$ Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! (firefox-bin:11674): Gtk-WARNING **: cannot open display: [1]+ Exit 1 firefox bill@home:~$ xhost + access control disabled, clients can connect from any host bill@home:~$ firefox & [1] 11681 bill@home:~$ *** nsExtensionManager::_disableObsoleteExtensions - failure, ca ing exception so finalize window can close *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application di tory, skipping. *** loading the extensions datasource *** ExtensionManager:_updateManifests: no access privileges to application di tory, skipping. bill@home:~$ xhost - access control enabled, only authorized clients can connect [1]+ Done firefox bill@home:~$ firefox & [1] 11727 bill@home:~$ =========================================================
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #22) > > I have still the same pb with debian sarge with firefox 1.0 > > I am getting this problem with firefox 1.0 under Suse Linux 9.0. It seems to > work fine when I log in as root, but when I log in as myself I get the Xlib > error. > > I don't know if anyone is reading this, but the problem has been fixed - here's how. I originally downloaded the tar file to /root/downloads, unpacked it there and ran the installation. It wanted to install to /root/downloads/firefox-installer, which I didn't want, so I changed the directory during the installation to /usr/local. It gave some error message, but seemed to work OK when I was logged in as root. But when I logged in as user, it gave the Xlib error noted above. So I uninstalled firefox, moved the tar file to /usr/local, unpacked it there and ran the installation without changing directory. It ran fine and firefox now works OK when I log in as user. Seems to be some problem with changing directory during installation, or perhaps with having the installation directory under root. Hope this helps someone.
I'm seeing this same problem on with the Debian 1.0.1-2 package. This is my first experience with firefox. I guess I'll go back to konqueror...
(In reply to comment #7) > [XDM-AUTHORIZATION-1] > My collegue who hit it suggests that XOpenDisplay generates a key based on the > pid and timestamp. He thinks that firefox is forking to run the wizard, but not > closing the previous X display connection before opening a new one for the > wizard. That's close, but the problem occurs because firefox doesn't fork after it's fiddled with the profiles. Problem 1 - duplicated sequence numbers For UNIX domain sockets, XDM-AUTHORIZATION-1 generates a key by encrypting the following data: (a) a shared secret, (b) the time in seconds, (c) the pid, and (d) a sequence number. The result is supposed to be unique. Unfortunately the sequence number is reset when the process calls exec, so if the first process lasts less than a second, the second process may end up with the same authentication data. Problem 2 - XCloseDisplay/XOpenDisplay race From the client's point of view, only one process has an X connection with that authentication data at any one time (note the FD_CLOEXEC in the strace output) so the XOpenDisplay ought to succeed. In practice, the client's X connection closure completes immediately; the second firefox process calls XOpenDisplay before the X server has processed the first connection closure. From the server's point of view, the two X connections overlap, albeit momentarily, and that is why it gives an error about the existing client. Firefox could easily work around this problem by: (a) sleeping before the exec, or (b) forking before execing the second process. Both these workarounds are bad - they would appear to any reasonable programmer to be operations with no useful effect, yet they are necessary for correct operation. I think the underlying bug is bad protocol design and the right place for workarounds is in Xlib.
Assignee: firefox → nobody
QA Contact: general → startup
Version: unspecified → Trunk
I'm getting this right now every time I attempt to start firefox and thunderbird. Essentially, these are completely useless to me. Seamonkey works though (yaay!). I've even tried renaming .mozilla to something other (so (I assume) no import windows would come up) and it still happens.
For anyone else that might be in my position, and needs to have firefox working without hacky workarounds for a large number of students, you can avoid this bug by precreating .mozilla/firefox in the new user's home directory. Here is a Perl script that can do it: https://svn.cs.pomona.edu/sys/dci/scripts/preconfigure-firefox
*** Bug 246701 has been marked as a duplicate of this bug. ***
Depends on: 394466
The patch in bug 394466 comment 1 may help with this. It explicitly calls XCloseDisplay before exec, instead of just letting the socket close on exec.
I think this should be fixed now. Can someone who can reproduce this please test Firefox 3 Beta 1? http://www.mozilla.com/en-US/firefox/all-beta.html
Not really fixed. I still get /tmp/firefox-3.0b1> ./firefox (Gecko:30863): GLib-GObject-WARNING **: IA__g_object_set_valist: construct property "show-crash-dialog" for object `GnomeProgram' can't be set after construction (Gecko:30863): GLib-GObject-WARNING **: IA__g_object_set_valist: construct property "show-crash-dialog" for object `GnomeProgram' can't be set after construction Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! Error: cannot open display: :0 Even after logging out and in again to restart X (and clean up what sockets previous starts might have left open). (Not sure though if I have seen the GLib-GObject-WARNING line before...) Well, as Stefan found out in comment 26 if I try often enough it finally opens (I had to try 5 times).
Hi everybody, actually i looking for how to solve the problem with my mozilla firefox. Currently i can't open and start my mozilla, when i press twice on mozilla icon in my dekstop one message box appear to my dekstop 'Abstract Error #13820'. I was thinking may be i have lose or missing some mozilla file, so I started to make a new mozilla installment but its same problem has came. Anyway, once its working well and again in other day this problem happened with my mozilla. What should I do to solve this problem?
Hi everybody, actually i looking for how to solve the problem with my mozilla firefox. Currently i can't open and start my mozilla, when i press twice on mozilla icon in my dekstop one message box appear to my dekstop 'Abstract Error #13820'. I was thinking may be i have lose or missing some mozilla file, so I started to make a new mozilla installment but its same problem has came. Anyway, once its working well and again in other day this problem happened with my mozilla. What should I do to solve this problem? I have mozilla version 1.8, working PC with Windows XP/ SP1.
(In reply to comment #41) > What should I do to solve this problem? You should ask this question in the forums at mozillazine.org or in the mozilla.support.mozilla-suite or mozilla.support.seamonkey newsgroups. But you should not spam a completely unrelated bug twice with support questions.
Product: Firefox → Toolkit
Still there, can provide a minimalistic installer ISO which manifests it with 10.0.3.
See Also: → https://bugs.freedesktop.org/show_bug.cgi?id=10665
Summary: Firefox does not start: getting "cannot open display" error → Firefox does not start: getting "XDM authorization key matches an existing client" "cannot open display" error
Whiteboard: [See comment 33 problem 1 for analysis, freedesktop bug for workaround]
(In reply to Marcus Münch from comment #0) > I installed the new Firefox 0.9RC release with the installer into ~/firefox > When I cd into this directory and try to start Firefox with ./firefox& , I > get > this error: > > Xlib: connection to ":0.0" refused by server > Xlib: XDM authorization key matches an existing client! > > (firefox-bin:7314): Gtk-WARNING **: cannot open display: > > [1]+ Exit 1 ./firefox > > What's wrong? Any other application works fine with my X-Display, including > Firefox 0.8 and Thunderbird 0.6 (both where NOT running while I was trying to > start Firefox 0.9RC). > > I can reproduce this always.

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: critical → --

Old bug, can be closed imho

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(dtownsend)

Please reopen if this is still an issue

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(dtownsend)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: