> 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
