Le 22-11-2018, à 07:35:08 -0800, Felix Finch a écrit :
On 20181122, Nathan Stratton Treadway wrote:
On Thu, Nov 22, 2018 at 07:51:48 +0100, steve wrote:
> No. If switch to another console, and launch a 'ls' for example, the
> cursor goes to the line and then nothing happens. Ctlr-x doesn't do
> anything. Opening a new one and launching htop for example freeze the
> terminal. But was it funny, is that I can firefox still works as
> expected. At this stage I normally shutdown the computer physically.
Hmmm, interesting... the system is not truely locked up, but perhaps
it's now unable to launch new processes, or something like that. (It
would be interesting to know if an instance of "htop" running on another
console continues keep running even after the segfault, for example.)
I have seen screen (the command!) leave the tty in a very confused state, where
it thinks the usable area is less than full size, such that scrolls for instance
only operate on a subsection.
Try "stty sane^J". If using screen or tmux, try ^D to exit and ^A^C or ^B^C to
open a new session. Sometimes I have cat'd a binary file by mistake and left
the tty so confused that I have to log out and back in. Do you have ssh set up,
and do you have a second computer you can ssh in from? Try ssh on that other
compputer just to have an independent tty available, and see if it behaves
normally after mutt locks things up.
I of course tried sshing the machine, but after password prompt, nothing
happened (I waited 3 minutes or so).
One problem with power cycling is the file system recovery after a power loss;
you can avoid that by starting a root sleep+reboot in the background, which you
abort if you don't need it, otherwise let it reboot for you if possible.
sudo su -
(sleep 300; reboot) &
^D
su was blocked too. In fact opening any new terminal left me with no
possibility to enter commands.
and on to your mutt crashing. If mutt locks up, wait 5 minutes and see it it
reboots on its own. If not, power cycle. You can use "shutdown -h now" instead
of reboot if you want.
Doesn't work either.
If nutt locks up but the other suggestions leave you with a working tty, or if
mutt doesn't lock up, you have 5 minutes to "sudo su -" again and kill the
sleep+reboot job.
Adjust the 300 second sleep to your patience; how quickly can you make mutt
lockup? How often do you wnat to kill and restart that sleeper, and how long do
you want to wait for it to reboot after a lockup?
You can start similar background jobs to report interesting data and wait a few
minutes, then on reboot, check its logged output.
while :; do date >>~/loggy; sleep 10; done &
You may need a nohup in there; try logging out with that running and make sure
it remans running. If mutt locks up, not the exact time, wiat 5 minutes, power
cycle, and check ~/loggy to see how long it kept logging.
Thanks Felix for this lengthy help, but it looks a bit too much for me
of an action. I'm getting too old for this kind of fun ;) That's why I
love Debian, it's so rock solid and stable that I don't need to go in
that kind of things (any more).
Best,
Steve
