Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 131308 - x11-apps/xinit-1.0.2-r3: xauth: (stdin):2: unknown command "539e6ee6eaed2a9d004e0cd61fb307d4"
Summary: x11-apps/xinit-1.0.2-r3: xauth: (stdin):2: unknown command "539e6ee6eaed2a9d...
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo X packagers
URL: https://bugs.freedesktop.org/show_bug...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-26 02:56 UTC by Martin Mokrejš
Modified: 2009-06-23 20:11 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
startx.patch (startx.patch,573 bytes, patch)
2006-09-19 03:16 UTC, Martin Mokrejš
Details | Diff
.Xauthority (.Xauthority,458 bytes, application/octet-stream)
2009-02-04 09:58 UTC, Martin Mokrejš
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Mokrejš 2006-04-26 02:56:03 UTC
After upgrading few days ago x11-apps/xdm-1.0.3 to -r1 package I am not able to start X on my laptop:

# cat /root/startx-bug.txt 
# startx
xauth:  creating new authority file /root/.serverauth.675
xauth: (stdin):2:  unknown command "539e6ee6eaed2a9d004e0cd61fb307d4"
xauth: (stdin):2:  unknown command "539e6ee6eaed2a9d004e0cd61fb307d4"

X Window System Version 7.0.0
Release Date: 21 December 2005
X Protocol Version 11, Revision 0, Release 7.0
Build Operating System:Linux 2.6.16-rc5 i686
Current Operating System: Linux vrapenec 2.6.17-rc1 #5 Thu Apr 20 10:51:51 CEST 2006 i686
Build Date: 04 April 2006



I have traced down already that the /usr/bin/startx script extracts in a for loop the auth keys, but it does not expect there are two keys: one for MIT and the other or XDM auth. I just verified grepping out just a one line "fixes" the problem:

for displayname in $authdisplay $hostname$authdisplay; do
    authcookie=`xauth list "$displayname" \
        | grep XDM | sed -n "s/.*$displayname[[:space:]*].*[[:space:]*]//p"` 2>/dev/null;
    echo "authcookie is $authcookie"
    if [ "z${authcookie}" = "z" ] ; then
        xauth -q << EOF
add $displayname . $mcookie
EOF


Further I even tried to have in startx:

echo "starting  xinit $clientargs -- $serverargs -deferglyphs 16 -cookie $authcookie &"
xinit $clientargs -- $serverargs -deferglyphs 16 -cookie $authcookie &

but still, I cannot start X through startx.
In contrast, xinit fires X fine.
Comment 1 Martin Mokrejš 2006-04-26 03:06:22 UTC
Well, this is the message which X spits out when started from startx. I had the impression that the xauth has to extract the XDM-AUTHORIZATION-1 key from the xauthority file, but maybe it should rather use the MIT-MAGIC-COOKIE. Or should teh server be recompiled with some extra USE flags to enable support for XDM-AUTHORIZATION-1?


AUDIT: Wed Apr 26 11:41:58 2006: 30688 X: client 1 rejected from local host
  Auth name: XDM-AUTHORIZATION-1 ID: -1
Xlib: connection to ":0.0" refused by server
Xlib: Protocol not supported by server


BTW: No Xsecurity.7 manpage exists, although referenced from X.7.
Comment 2 Martin Mokrejš 2006-09-19 03:16:31 UTC
Created attachment 97391 [details, diff]
startx.patch

This is my patch to get it working. Why is is necessary I do not know, but have hit this problem again. I have x11-apps/xinit-1.0.2-r6 now.
Comment 3 Donnie Berkholz (RETIRED) gentoo-dev 2006-09-19 06:43:35 UTC
It should probably be using the MIT one, I don't even have any xdm-auth-1 keys in my list.
Comment 4 Martin Mokrejš 2006-09-27 04:24:37 UTC
I think you are right, older is the MIT key stuff, I think coming from X11R5 or similarly old. I still don't know why not more people hit this problem. :(


# emerge --info
Portage 2.1.2_pre1-r3 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17.11 i686)
=================================================================
System uname: 2.6.17.11 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
Gentoo Base System version 1.12.5
Last Sync: Tue, 26 Sep 2006 10:30:01 +0000
app-admin/eselect-compiler: 2.0.0_rc2-r1
dev-java/java-config: 2.0.30
dev-lang/python:     2.3.4-r1, 2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r1
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /usr/spool/PBS /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LINGUAS="en cs cz"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 FFmpeg X Xaw3d a52 aac aalib acpi alsa amr apache2 apm asf ati avi berkdb bitmap-fonts bonobo caca cairo cdparanoia cdr cli cpudetection crypt cscope ctype cups curl dba dga directfb divx divx5 divx5linux dlloader dri dts dv dvb dvd dvdr dvdread eds elibc_glibc emacs emacs-w3 emboss emf encode ethereal evo f77 faad faad2 fam fame fbcon ffmpeg flac flash foomaticdb fortran fvwm fvwm2 gb gd gdbm ggi gif gphoto2 gpm gstreamer gtk gtk2 gtkhtml highvolume i8x0 icc iconv ieee1394 ifc imagemagick imlib imlib2 inifile innodb input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog ithreads java jpeg kerberos kernel_linux lcms leim libcaca libedit libg++ libwww linguas_cs linguas_cz linguas_en lirc live lzo mad matroska mcal mesa mhash mikmod ming mmx mmx2 mmxext mng modplug motif mozilla mp3 mpeg mule musepack mysql ncurses network nls nptl nptlonly ogg oggvorbis opengl oss pam pcre pda pdf pdflib perl plotutils plugin png poppler ppds pppd pthread pthreads python qt qt3 qt4 qtx quicktime readline reflection rtc samba scanner scp server session slp spell spl sse sse2 ssl stroke svg tcl tcltk tcpd tetex theora thread threads tiff tk truetype truetype-fonts type1-fonts udev unicode usb userland_GNU userlocales v4l v4l2 vcd video_cards_ati vorbis win32codecs winvidix wmf x264 xanim xml xml2 xmms xorg xosd xprint xv xvid xvmc zeo zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 5 Zrajm C Akfohg 2006-11-10 15:03:16 UTC
I had the same problem. It went away when I simply removed my ~/.Xauthority file.

If I do so startx generates a new one, and everything works fine. This new .Xauthority file is then cleared of it's contents when I terminate X (i.e. the file remains, but is emptied of contents).

Is this normal? How large is the .Xauthority file normally? (My old one was 913 bytes, the one generated if I remove that one is only 57 bytes... Is this cause for concern?)

Should the ~/.Xauthority file be re-generated each time I start X? Or should it remain the same?
Comment 6 Zrajm C Akfohg 2006-11-10 15:08:06 UTC
BTW, I'm using x11-apps/xinit-1.0.2-r6, on a freshly installed system. (Only the files in /home/ are retained from my old Gentoo install.)
Comment 7 Joshua Baergen (RETIRED) gentoo-dev 2006-12-30 09:56:03 UTC
(In reply to comment #5)
> Is this normal? How large is the .Xauthority file normally? (My old one was 913
> bytes, the one generated if I remove that one is only 57 bytes... Is this cause
> for concern?)
> 
> Should the ~/.Xauthority file be re-generated each time I start X? Or should it
> remain the same?
> 

josh@mifflin ~ $ ls -l .Xauthority 
-rw------- 1 josh josh 174 2006-12-30 09:25 .Xauthority

Looking at its contents, I think the appropriate entries are replaced on start.  For example, I still have entries from my old laptop in there (I can tell by the domain name).

Martin, does this solution work for you?  Please re-open when you respond.
Comment 8 Martin Mokrejš 2009-02-04 09:57:36 UTC
It still happens time to time. I suspect startx/auth is fooled by several entries
in the .Xauthority file. A pair of lines is for hostname.domain, a pair for hostname/unix, a pair for my occasional different IP address (currently not resolvable), a pair for my OpenVPN interface (not resolvable either).

Yes, removing the file cures the problem temporarily.

$ xauth list
vrapenec.doma:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
10.8.0.6:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
vrapenec/unix:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
vrapenec.doma:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
10.8.0.6:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
vrapenec/unix:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
10.5.2.51:0  MIT-MAGIC-COOKIE-1  aa50b84c2399006bab8e41c820fa921d
vrapenec/unix:10  MIT-MAGIC-COOKIE-1  2861fe1448b374327572c4df4c0cfcdc
10.5.2.51:0  XDM-AUTHORIZATION-1  3637bae0fb8f94e700bd454fe284e82d
$ xauth 
Using authority file /home/mmokrejs/.Xauthority
xauth> source /home/mmokrejs/.Xauthority
xauth: /home/mmokrejs/.Xauthority:2:  line too long
xauth> list
vrapenec.doma:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
10.8.0.6:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
vrapenec/unix:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
vrapenec.doma:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
10.8.0.6:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
vrapenec/unix:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
10.5.2.51:0  MIT-MAGIC-COOKIE-1  aa50b84c2399006bab8e41c820fa921d
vrapenec/unix:10  MIT-MAGIC-COOKIE-1  2861fe1448b374327572c4df4c0cfcdc
10.5.2.51:0  XDM-AUTHORIZATION-1  3637bae0fb8f94e700bd454fe284e82d
xauth> 

x11-apps/xinit-1.0.8-r3, x11-base/xorg-server-1.5.3-r1
Comment 9 Martin Mokrejš 2009-02-04 09:58:43 UTC
Created attachment 180890 [details]
.Xauthority
Comment 10 Martin Mokrejš 2009-02-21 17:50:18 UTC
(In reply to comment #8)
> $ xauth list
> vrapenec.doma:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
> 10.8.0.6:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
> vrapenec/unix:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
> vrapenec.doma:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
> 10.8.0.6:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
> vrapenec/unix:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
> 10.5.2.51:0  MIT-MAGIC-COOKIE-1  aa50b84c2399006bab8e41c820fa921d
> vrapenec/unix:10  MIT-MAGIC-COOKIE-1  2861fe1448b374327572c4df4c0cfcdc
> 10.5.2.51:0  XDM-AUTHORIZATION-1  3637bae0fb8f94e700bd454fe284e82d
> $ xauth 
> Using authority file /home/mmokrejs/.Xauthority
> xauth> source /home/mmokrejs/.Xauthority
> xauth: /home/mmokrejs/.Xauthority:2:  line too long
> xauth> list
> vrapenec.doma:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
> 10.8.0.6:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
> vrapenec/unix:0  MIT-MAGIC-COOKIE-1  1d9e926170db4b8ac8b4c57fc826865b
> vrapenec.doma:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
> 10.8.0.6:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
> vrapenec/unix:0  XDM-AUTHORIZATION-1  4733e9568195d8c5008a42f9107569c6
> 10.5.2.51:0  MIT-MAGIC-COOKIE-1  aa50b84c2399006bab8e41c820fa921d
> vrapenec/unix:10  MIT-MAGIC-COOKIE-1  2861fe1448b374327572c4df4c0cfcdc
> 10.5.2.51:0  XDM-AUTHORIZATION-1  3637bae0fb8f94e700bd454fe284e82d
> xauth> 

Regarding the line too long issue I haven't found anything around on the net,
maybe except this (look for "line too long errors from xauth" in the archive"):
http://www.oldlinux.org/Linux.old/mail-archive/linux-admin/Volume2/digest16

Comment 11 Martin Mokrejš 2009-02-21 19:36:27 UTC
(In reply to comment #0)
> After upgrading few days ago x11-apps/xdm-1.0.3 to -r1 package I am not able 
> to start X on my laptop:
> 
> # cat /root/startx-bug.txt
> # startx
> xauth:  creating new authority file /root/.serverauth.675
> xauth: (stdin):2:  unknown command "539e6ee6eaed2a9d004e0cd61fb307d4"
> xauth: (stdin):2:  unknown command "539e6ee6eaed2a9d004e0cd61fb307d4"
> 

It seems this is similar to https://bugs.freedesktop.org/show_bug.cgi?id=13462
issue in the approach to take just of the two cookies.

Comment 12 Martin Mokrejš 2009-02-21 19:51:45 UTC
I could not resist and opened a bug upstream about the "line too long issue" to get the message from xauth improved in future: https://bugs.freedesktop.org/show_bug.cgi?id=20245
Comment 13 Alan Coopersmith 2009-02-23 16:32:35 UTC
(In reply to comment #8)
> $ xauth 
> Using authority file /home/mmokrejs/.Xauthority
> xauth> source /home/mmokrejs/.Xauthority
> xauth: /home/mmokrejs/.Xauthority:2:  line too long

Don't do that.  .Xauthority is a binary file containing your cookies, it
is not a valid script file that can be used as the argument to xauth's
source command.
Comment 14 Rémi Cardona (RETIRED) gentoo-dev 2009-06-23 20:11:23 UTC
The Xauth bits are dark magic, even to most upstream X devs.

There's little we can do here, let's track the bug upstream. Here's to hoping someone actually looks at it someday. :)

Thanks