> What should a functional control-z tell me? If control-Z works, your transport (ssh) and terminal are still fundamentally intact, and responsive to low-level traffic and out-of-band signals. (It means that mutt is responsive to signals too, for that matter -- once it receives them.) Does mutt work again once you bring it back to foreground, or does it remain hung? If it hangs, and you type a bunch of stuff followed by control-Z, and then foreground mutt, does all the stuff you typed suddenly appear to execute at once? Does it appear to have already executed long ago? Or is it ignored?
This all serves to indicate what stage things are at when mutt appears to be unresponsive. You might also check the debug log during a suspend instead of after a kill; this could help pinpoint more exactly what mutt thought it was up to. If you have gdb installed and you're familiar with it, you might try attaching gdb to the hung mutt process from within another terminal. That is: window 1 window 2 ------------------------------ ------------------------------ + ssh in - ssh in + run mutt - get mutt's process id from "ps" for example: 14001 + do stuff, wait for a hang - attach gdb to the mutt process for example: gdb /usr/bin/mutt 14001 - get a backtrace, minimally type: "backtrace" This will tell you more finely than debug logs will what mutt is doing at an exact moment that it appears hung, but it's quite possible that it's just waiting for input that's simply not arriving. The logs will tell what it *has* been doing up until that, but it might not be anything special. Honestly this has the feel of an ordinary session timeout at the network level, which wouldn't be surprising. But you said that it happens only with mutt, and not even with an idle shell. That's what seems strange to me. -- -D. [EMAIL PROTECTED] NSIT University of Chicago