Emerge build: xfree-4.2.1.ebuild make.conf cflags=march=pentium3 -03 -pipe(used to build my entire system). I emerged xfree, and setup xdm to process remote xdmcp requests(I commented out Display.requestPort in xdm-config & enabled direct/broadcast xdmcp access to everyone("*") in Xaccess). I startup xdm in debug mode, and all goes ok with the following last statements being printed on my linuxbox: "creating socket 177 Created chooser socket 5 WaitForSomething" Now I start-up my remote x-server(Xwin32-5.1 running on Windows XP) and enable xdmcp broadcast. I get nothing(no chooser or login window like I normally get). After couple of minutes or so , I get a message within xwin32 logs as "XDM: too many retransmissions". Looking at my Linuxbox, a couple of lines have been spewed out by xdm: something like "select returns 1" and "request 1 1 1"(or if I'm using indirect xdmcp..."Indirect request"). Aside from those few lines I get _nothing_ else, and "WaitForSomething" doesn't even appear again. I then found out xdm is hogging 99.9% of my cpu after recieving the request, where I can't sigterm it, but only sigkill it. I did a sigabrt on it to generate a core dump. And this is the rough output I get from the gdb bt: 13 - __libc_start_main 12 - main() 11 - WaitForSomething() 10 - SendFailed() 09 - SendFailed() 08 - Willing() (following from /lib/libc.so.6) 07 - fgets () 06 - _IO_getline() 05 - _IO_getline_info() 04 - __uflow() 03 - _IO_default_uflow() 02 - _IO_new_file_underflow() 01 - __DTOR_END__() 00 - read() I don't know why XDM is sucking so much CPU and not doing anything. I've tried the same configuration using RH8.0, RH7.3 and RH7.2, and for all those cases xdm worked for me with xwin-32. Thinking the problem has to do with my cflags, I commented the entry out of my make.conf and compiled xfree-4.2.1 again: same thing. Then I went down to xfree-4.2.0-r12.ebuild, and again same problem. Could it be a gcc problem? Don't know. I will try to provide more information if neccessary. Regards, Kashif
Forgot one thing: XDM doesn't spit out any info into its log.
Ok, I solved(actually worked around) the bug I reported. The problem is when XDM executes the default DisplayManager.willing entry in xdm-config: "su nobody -c /usr/X11R6/lib/X11/xdm/Xwilling", user nobody doesn't have a valid interpreter(it's set to /bin/false in passwd). So the whole su statement returns 1 with no output on stdout. I haven't looked at the xdm source code, but my guess is that xdm *assumes* it will recieve some output on stdout and just waits in some busy loop on a non-blocking read. You don't encounter such problems on redhat systems, because /sbin/nologin is mapped to user nobody on login, which results in the message: "This account is currently not available." in your chooser window. Fix: Remove the 'su nobody -c' part, or just leave a blank entry for DisplayManager.willing(resulting in "Willing to manage" in your chooser window). Real fix: Some xdm hacker should look into Willing() and handle case where no output is recieved.
Good to hear you got a work around. I feel though that we should not close this until I get the time to really fix it. Some support in the future to get this resolved will be appreciated. I do however need to resolve some other issues, so it can be a while before I get to it ...
Ok, I'll investigate the exact reason why xdm hogs cpu when it recieves no stdout from executing the willing program. Hopefully I can fix it, at which time I'll post the patch. Kashif
Same problem here with XFree version 4.3.0-r1. Removing the 'su nobody' stuff from xdm-config does not help at all. tbekel@shimanto tbekel $ emerge info Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.2-r0) ================================================================= System uname: 2.4.20 i686 Pentium III (Coppermine) GENTOO_MIRRORS="ftp://ftp.fhh.opensource-mirror.de/pub/gentoo.org ftp://sunsite.rwth-aachen.de/pub/Linux/gentoo http://distro.ibiblio.org/pub/linux/distributions/gentoo http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config /etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss crypt cups gnome libg++ mikmod ncurses spell xml2 gdbm berkdb slang arts svga guile gpm tcpd pam libwww python esd imlib oggvorbis motif -3dnow acpi apm avi dvd encode fbcon gd gif gtk java jpeg kde -maildir mbox mmx mozilla mpeg mysql nls odbc opengl pcmcia pdflib perl png qt quicktime readline samba sdl ssl sse tcltk tetex tiff truetype X xmms xv zlib" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE" CXXFLAGS="-march=pentium3 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
Ran into this problem again and it took me quite some time to remember how I solved it last time... just use a user with a valid shell instead of "nobody" there and everything is fine. Maybe not a solution, but a nice workaround.
Updated the summary line to include "Xwilling" for the case someone wants to enter a duplicate of this bug as I was just going to do...
Would be nice if this could be fixed with the next Xfree release.
I'm assuming this is fixed by now...please say if not.
Still looks to be a problem in modular X.
Fixed (finally) in xdm-1.0.3-r1, thanks! Feel free to file an upstream bug at bugs.freedesktop.org in the xorg product if you have any interest in getting the lack of handling of the no-output case fixed. If you do, please CC me.
*** Bug 97091 has been marked as a duplicate of this bug. ***
