Closed Bug 246313 Opened 20 years ago Closed 5 months ago

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

Categories

(Toolkit :: Startup and Profile System, defect)

x86
Linux
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: marcus, Unassigned)

References

Details

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

Attachments

(1 file)

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.
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: 5 months ago
Flags: needinfo?(dtownsend)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: