After upgrading to the latest version of openoffice, all the oo* commands flash the splash screen up for a fraction of a second and then fail with: XDM authorization key matches an existing client!/usr/lib64/openoffice/program/soffice.bin X11 error: Can't open display: Set DISPLAY environment variable, use -display option or check permissions of your X-Server (See "man X" resp. "man xhost" for details) openoffice-3.1.1 worked yesterday before the update. Reproducible: Always $ emerge --info Portage 2.2_rc63 (default/linux/amd64/10.0, gcc-4.4.3, glibc-2.11-r1, 2.6.32-gentoo-r5 x86_64) ================================================================= System uname: Linux-2.6.32-gentoo-r5-x86_64-Intel-R-_Core-TM-2_CPU_T5500_@_1.66GHz-with-gentoo-2.0.1 Timestamp of tree: Sat, 20 Feb 2010 23:15:01 +0000 app-shells/bash: 4.1_p2 dev-lang/python: 2.6.4-r1, 3.1.1-r1 dev-util/cmake: 2.8.0-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.20 sys-devel/gcc: 4.4.3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.32 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="@FREE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--ask" FEATURES="assume-digests distlocks fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.netnitco.net http://mirror.mcs.anl.gov/pub/gentoo/ http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ http://mirror.datapipe.net/gentoo ftp://mirror.datapipe.net/gentoo" LDFLAGS="-Wl,-O1,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/njw /usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X acl acpi afs alsa amd64 berkdb bzip2 cairo caps cdr cli cracklib crypt cxx dbus dri dvd dvdr emacs fortran gd gdbm gimp gpm gtk hal iconv jpeg kerberos latex mmx modules mudflap multilib ncurses nptl nptlonly opengl openmp pam pcre perl png pppd python readline reflection session smp spl sse sse2 ssl ssse3 sysfs tcpd truetype unicode xorg xscreensaver zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" SANE_BACKENDS="epson2" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
*** This bug has been marked as a duplicate of bug 306211 ***
I'm still observing this after a rebuild (using the ebuild committed at 2010/02/22 22:20:50). I don't think this is the same as bug 306211 because I don't run KDE and don't have any qt libraries installed. I've also noticed that I can occasionally get oowriter to start (maybe once in every 20-30 tries), so this looks like some sort of race condition.
Can you open it as root? Besides the Qt-problem: Usually such bugs are caused by a broken graphics driver installation (especially the opengl part)
Same behavior as root: it usually fails but ocasionlly works. I haven't observed any other problems with graphics, but I don't tend to stress the drivers much, so it could be that. Any suggestions on how to test for a driver problem? Should I remerge my divers? Would remerging openoffice with USE="-opengl" be useful?
(In reply to comment #4) > Same behavior as root: it usually fails but ocasionlly works. > > I haven't observed any other problems with graphics, but I don't tend to stress > the drivers much, so it could be that. Any suggestions on how to test for a > driver problem? Should I remerge my divers? Would remerging openoffice with > USE="-opengl" be useful? > Hmmm, weird - usually running as root helps in these situations. Two things come to my mind: Are your opengl-settings correct? (with eselect opengl) Also: Is there something "special" about your setup? (like remote desktop or such). And: which desktop environment are you using?
(In reply to comment #5) > (In reply to comment #4) > > Same behavior as root: it usually fails but ocasionlly works. just my 2cts. Have you enough free space left on your file system. If not openoffice will fail randomly and without warning.
(In reply to comment #5) > Hmmm, weird - usually running as root helps in these situations. Two things > come to my mind: Are your opengl-settings correct? (with eselect opengl) Also: I assume so. There's only one option. # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * > Is there something "special" about your setup? (like remote desktop or such). > And: which desktop environment are you using? > I'm running FVWM. Aside from that I don't think there's anything unusual about my setup. And I'm not low on disk space.
I'm just confirming that I have the same problem, with openoffice closing. I recently added the raster flag in my package.use and the next reboot, openoffice didn't work. Upon recompiling qt-gui without the raster USE flag, it functions again.
I've got the same problem. FVWM (no KDE at all), XDM, qt-gui without raster USE flag. OOo 3.1.1 worked well, but 3.2.0 does not.
Same problem here, starting the openoffice components only works sporadically.
(In reply to comment #10) > Same problem here, starting the openoffice components only works sporadically. > I can confirm it as well. I use xdm + xfce4, no kde apps except kstars. Putting localhost in a DISPLAY variable helps: > ooffice XDM authorization key matches an existing client!/usr/lib/openoffice/program/soffice.bin X11 error: Can't open display: Set DISPLAY environment variable, use -display option or check permissions of your X-Server (See "man X" resp. "man xhost" for details) > echo $DISPLAY :0.0 > export DISPLAY=localhost:0.0 > ooffice
I can confirm that adding localhost to the DISPLAY variable lets oowriter start consistently. Any idea what that indicates about the problem?
Does anybody who experiences this problem not use xdm. It seems most use it. Just trying to narrow things down. Here I am using xdm + xfce.
When I start the my xfce session via startx everything is fine. Display variable is also set to :0.0. So xdm probably messes something up.
I tested it on two other machines running xfce4 + slim and there is no problem. Only the xfce4 + XDM setup is problematic.
I was seeing this same problem, it appears as though it may be the race condition in this old bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292388 As that report suggests, adding the following line to /etc/X11/xdm/xdm-config worked around the problem. DisplayManager*authName: MIT-MAGIC-COOKIE-1 Can anyone comment on the security implications of this work around?
Same here. XDM + xfce. 3.1.1 worked fine, 3.2.0 doesn't.
I'm on xdm+openbox michael@panther ~ $ export DISPLAY=localhost:0.0 michael@panther ~ $ ooffice At this point there's nothing that happens. Everything else I'm experience seems pretty close to the bug report.
I also wanted to mention: If I run 'xhost +' I can runs ooffice. If I run 'xhost -' I can no longer run ooffice. Obviously this isn't a fix as anyone can run anything on my display from anywhere. Hopefully it's a help in fixing it though.
(In reply to comment #19) > I also wanted to mention: > If I run 'xhost +' I can runs ooffice. > If I run 'xhost -' I can no longer run ooffice. xhost +localhost is sufficient. I didn't notice this bug in the first place, as i have a xhost +localhost in my .xsession. Only after i installed OOo on another machine (only differing in hardware and some details) that doesn't have that xhost line, i wondered why OOo doesn't start up there. The other setup is similar to what is mentioned here: xdm, xfce, OOo build with USE=gnome.
(In reply to comment #20) > (In reply to comment #19) > > I also wanted to mention: > > If I run 'xhost +' I can runs ooffice. > > If I run 'xhost -' I can no longer run ooffice. True for me. > xhost +localhost is sufficient. Not true for me. I do have ipv6 support in everywhere and "xhost +localhost" adds only ipv4 support. However xhost dosn't seem to like ipv6 localhost address: $ xhost +inet6:localhost xhost: unable to get inet6 address for "localhost" It seems to be some race condition as following always fails: $ cd /usr/lib64/openoffice/program ; ./soffice.bin and following always works: $ cd /usr/lib64/openoffice/program ; strace ./soffice.bin Settings in use: USE="-* cups pam" LINGUAS="en fi"
I use xdm+xfce, openoffice 3.2. Tried the suggested solutions, both works for me (assuming ipv4): 1. solution: export DISPLAY=localhost:0.0 (Does not work with original settings, DISPLAY=:0.0) 2. solution: xshot +localhost
I have been having the same problem and can confirm that export DISPLAY="localhost:0.0" at a terminal will allow me to run OpenOffice applications, where not doing so will cause this error.
(In reply to comment #23) > I have been having the same problem and can confirm that > > export DISPLAY="localhost:0.0" > > at a terminal will allow me to run OpenOffice applications, where not doing so > will cause this error. > The above comment sums up what I'm seeing too. OpenOffice-3.2.1 works great on the command line. I see the above error when launching from one of my FvwmButton icons. I am running FVWM and XDM, if that information is related.
I can actually no longer reproduce this problem. oowriter will still sometimes display "XDM authorization key matches an existing client!" when started, but this no longer causes a display error. $ emerge -pqv openoffice xdm [ebuild R ] x11-apps/xdm-1.1.8 USE="pam -debug -ipv6" [ebuild R ] app-office/openoffice-3.2.1 USE="dbus gtk opengl pam (-aqua) -bash-completion -binfilter -cups -debug -eds -gnome -gstreamer -java -kde (-kdeenablefinal) -ldap -nsplugin -odk -templates" LINGUAS="-af -ar -as_IN -be_BY -bg -bn -br -brx -bs -ca -cs -cy -da -de -dgo -dz -el -en -en_GB -en_US -en_ZA -eo -es -et -eu -fa -fi -fr -ga -gl -gu -he -hi_IN -hr -hu -id -it -ja -ka -kk -km -kn_IN -ko -kok -ks -ku -lt -mai -mk -ml_IN -mn -mni -mr_IN -nb -ne -nl -nn -nr -ns -oc -or_IN -pa_IN -pl -pt -pt_BR -ru -rw -sa_IN -sat -sd -sh -sk -sl -sr -ss -st -sv -sw_TZ -ta -ta_IN -te_IN -tg -th -ti_ER -tn -tr -ts -uk -ur_IN -uz -ve -vi -xh -zh_CN -zh_TW -zu" I'll leave the bug open since this still seems to be affecting other people.
This is more of a xorg-server issue; I've attached a patch for it upstream.
Lot's of good comments and I agree - this is not an OOo bug
