segfault causes system freeze

[steve]

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