The Problem: I was installing Gentoo on an old machine and while I was waiting for some compliling, I decided to check my mail. So I ssh'ed over to my main machine, logged in, and typed mutt then enter. Hang. Superhang - not even a caplock light to blink. But I could tell that the machine was still churning away with the compile. So I walked over to the machine I had logged into and logged back to the first one (the hung one). I could see mutt in the process list. I killed it and walked back to the new machine. It was fine. No problems. I figured this was just the result of me using an old machine while making it work very hard. But then I did an install on a more powerful machine at work and logged in to my home machine and tried mutt again. I do this all day and I never have problems, but with the new Gentoo, it also died in the same way, i.e. locking up the client machine. Again I had to go to a different machine to log into the hung one to release it from the death grip. Since so many components are involved, I don't know exactly to whom I should send this bug. But since the sum of the parts causes an unexcusably nasty crash, I thought that the Gentoo team might be interested in it. After a bit of experimentation with this problem, I discovered that it was related to having a TERM setting of "linux" (which is the Gentoo default for text consoles AFAIK). When I changed the TERM setting to 'vt100', it functioned ok (except the color highlighting wasn't very good). When I do this log in and mutt from an xterm (I use aterm), it's fine - no problems. When I log in at the console of the target machine itself and run mutt right from that machines console (no ssh), it all works fine (even with TERM='linux'). The problem is just when logging in remotely from a text console and then running mutt. Other programs work fine (I've not found another problem one). When troubleshooting, I can log into the target machine and see that it's trying to run mutt. If I kill the mutt there, nothing different happens. Then I log into the ssh client machine (from yet another) and kill the ssh. Then the hung console comes back to life. Perhaps this could be done using Alt-F2, etc, but the keyboard is 100% locked so we'll never know. An interesting thing is that after the kill is ordered, I sometimes see a message from mutt that should have appeared on the display: Reading imap://blah.com/INBOX...Killed by signal 15. I tried to run mutt like this: mutt -F /dev/null This should factor out any funky thing in my .muttrc. Same problem. Any help would be appreciated. Reproducible: Always Steps to Reproduce: 1.Get two updated Gentoo machines. 2.Log from one to another from a text console using ssh. 3.Run mutt. Bang you're dead. Actual Results: Complete console IO hang. Not even keyboard lights can be toggled. Expected Results: It should have continued to allow user interaction. It doesn't hang with TERM='vt100'. LOCAL SYSTEM (I'm sitting here) ------------ echo $TERM linux uname -a Linux mindnoise 2.6.11-gentoo-r11 #1 Wed Aug 3 12:13:58 PDT 2005 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux ssh -v OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004 ldd /usr/bin/ssh linux-gate.so.1 => (0xffffe000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7fcc000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7efa000) libutil.so.1 => /lib/libutil.so.1 (0xb7ef6000) libz.so.1 => /lib/libz.so.1 (0xb7ee7000) libnsl.so.1 => /lib/libnsl.so.1 (0xb7ed2000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7ea4000) libc.so.6 => /lib/libc.so.6 (0xb7d8c000) libdl.so.2 => /lib/libdl.so.2 (0xb7d88000) /lib/ld-linux.so.2 (0xb7feb000) ldd /sbin/agetty linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/libc.so.6 (0xb7ec9000) /lib/ld-linux.so.2 (0xb7feb000) REMOTE SYSTEM (My mail lives here) ------------- uname -a Linux raven 2.6.10-gentoo-r6 #1 Sun Mar 20 14:22:51 PST 2005 i686 Celeron (Coppermine) GenuineIntel GNU/Linux ldd /usr/bin/mutt linux-gate.so.1 => (0xffffe000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7f9c000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0xb7f6a000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7e69000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0xb7e63000) libc.so.6 => /lib/libc.so.6 (0xb7d36000) libgpm.so.1 => /lib/libgpm.so.1 (0xb7d30000) libdl.so.2 => /lib/libdl.so.2 (0xb7d2c000) /lib/ld-linux.so.2 (0xb7fe9000) ldd /usr/sbin/sshd linux-gate.so.1 => (0xffffe000) libwrap.so.0 => /lib/libwrap.so.0 (0xb7fd6000) libpam.so.0 => /lib/libpam.so.0 (0xb7fcd000) libdl.so.2 => /lib/libdl.so.2 (0xb7fc9000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7fb5000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7eb4000) libutil.so.1 => /lib/libutil.so.1 (0xb7eb0000) libz.so.1 => /lib/libz.so.1 (0xb7e9e000) libnsl.so.1 => /lib/libnsl.so.1 (0xb7e86000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7e59000) libc.so.6 => /lib/libc.so.6 (0xb7d2c000) /lib/ld-linux.so.2 (0xb7fe9000) emerge mutt --info Gentoo Base System version 1.6.13 Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r0, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 Celeron (Coppermine) dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo ftp://csociety-ftp.ecn.purdue.edu/pub/gentoo/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ ftp://gentoo.chem.wisc.edu/gentoo/ ftp://cudlug.cudenver.edu/pub/mirrors/distributions/gentoo/ http://gentoo.mirrors.pair.com/ ftp://gentoo.mirrors.pair.com/ ftp://gentoo.ccccom.com ftp://gentoo.mirrors.tds.net/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ ftp://ftp.ndlug.nd.edu/pub/gentoo/ http://gentoo.eliteitminds.com ftp://linux.cs.lewisu.edu/gentoo/ ftp://mirror.usu.edu/mirrors/gentoo/" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm arts avi berkdb bitmap-fonts crypt cups emboss encode esd fam foomaticdb fortran gdbm gif gnome gphoto2 gpm gtk gtk2 imap imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses network nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline real sdl spell ssl svga tcpd tetex tiff truetype truetype-fonts type1-fonts vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
One more thing I should mention to those with this problem who just need it roughly cured - by using "app-misc/screen" on the client end, this problem does not occur. You can even change the TERM to "linux" and it's functional.
Does it happen if you ssh localhost ? I cannot reproduce this, neither with official ebuild nor with mine. Cheers, Ferdy
I'll try to do a 'ssh localhost' the next time I'm at the machine. For now I can say that ssh'ing to it and then 'ssh localhost' does produce the problem. But I suspect this is a result of the ultimate terminal forwarding the TERM value through each connection. It's like mutt asks for some crazy terminal feature that works most of the time, but with this combination, does not. I do also know that mutt runs 100% fine from the console on the machine it's running on (text, xterms, whatever). So I'm not surprised that ssh to itself isn't showing the problem. Though that is a good test. Any more ideas for sensible things to test would be welcome.
What does emerge -pv mutt show ? Cheers, Ferdy
emerge -pv mutt [ebuild R ] mail-client/mutt-1.5.8-r2 -buffysize -cjk +crypt +imap -mbox +nls -nntp -sasl -slang +ssl -vanilla 0 kB
(In reply to comment #2) > Does it happen if you ssh localhost ? On the local machine itself, doing an ssh localhost and then mutt from that produces correct behavior with no problems. Any more things I should check for?
Maybe try to build it with 'vanilla' to see if any of the patches is causing it. Or try switching from ncurses to slang and see if you can still reproduce it. Cheers, Ferdy
(In reply to comment #7) > Maybe try to build it with 'vanilla' to see if any of the patches is causing it. > Or try switching from ncurses to slang and see if you can still reproduce it. Ok, vanilla also has the problem, but... USE='slang' emerge mutt -u did work! So you've definitely isolated it down to mutt/ncurses interaction. I wonder if there's an ncurses test program.
I don't know really what might be going on there... I'd say if USE="slang" fixes your problem just stay there because I can't reproduce your bug. Probably this is one of those weird bugs only hits one or two users; I have no other way to help. May I close this as ->CANTFIX ? Cheers, Ferdy
(In reply to comment #9) I agree. My setup is pretty weird and you fixed my situation with the slang tip. More importantly, you've managed to pass the suspicion on to ncurses, so if this continues to be a problem in subsequent updates, I'll focus on that. That sounds reasonable, right? Thanks for your help.
Forgot to close. BTW, mutt-1.5.11 is in the tree. Maybe you should send this upstream if it still fails. Cheers, Ferdy
