how to analyze a freeze

[mike acker]

when an o/s has a hard freeze: unable to move mouse, no response to keybd -- how can this be analyzed?

supposedly ctrl-alt-backspace should cancel and restart the X-window UI.
if that fails -- it's power off and restart

are there any logs that would give any insight into such issues ?

This page seems helpful...

[Bulkley]

Most freezes are hardware related but not all. Further, many are video related in which case the kernel is purring along quite happily while you can't use your machine. At your next crash stop and observe anything and everything. Are any fans running? ?ny noises? What were you doing when it froze? Make notes. Then try shutting it down as follows: with your right hand hold down Alt+SysRq (print screen key) and with your left hand enter REISUB. Go ahead and try it now. If it doesn't do anything you will need to turn on this function. For some reason some Debian releases came with it turned off. Anyway, if REISUB works then your kernel is running.

When it comes to hardware everything can and does fail. I start by blowing the dust out and checking the fans. Note that fans are relatively cheap so replacing them is a no-brainer. I re=seat every electrical connection including memory sticks. Sometimes I run the machine with the back off and gently tap things with a pencil or a plastic swizzle stick; anything will do as long as it does not conduct electricity. If there is a bad connection, such as a cold solder joint, gentle tapping might trigger the freeze.

Do research on line. A search for a specific model computer or circuit board might get hits for chronic problems. I once found that a mother board I had was known for the failure I had.

[bw123]

when an o/s has a hard freeze: unable to move mouse, no response to keybd -- how can this be analyzed?

I think that would depend on what o/s you are having the issue on? If it's testing/sid or some frankendebian put together from all over the place, then I think it's tougher to solve. If you are talking about debian stretch then I think a good analysis might go something like this, in no particular order:

Can you reproduce it consistently?
Does it happen only running X?
Does it happen only on one user account?
Any hint in the logs?
Is it a new problem?
New hardware added/reconfigured recently?
Third party repos, other foreign software added?
Anything changed in the bios from defaults?
Does it happen with a live system?

are there any logs that would give any insight into such issues ?

Any one of the logs might give a clue, and that's probably the first place I'd look.

[mike acker]

thanks

i'll be working on my trouble-shooting

the document I found is dated 2012; a bit dated for this kind of work.

this problem -- happened twice on LMDE/2 Guest system and once on my Debian 9.30 -- this week. It reminds me of a wait state bug where the system is waiting on an in-active and incomplete event -- the old missed interrupt thing.

I tried the ALT+F2 option and did get into a text terminal. But i need to learn what to do when I get there. what I'm looking for is to find and cancel the program that is holding things up. methinks it's actually the xwindow itself as in the lock state the mouse won't move. taking out the x-window will likely take all the running programs down too so the total option is likely getting through an orderly shutdown rather than a power off crash stop.

[None1975]

I tried the ALT+F2 option and did get into a text terminal. But i need to learn what to do when I get there. what I'm looking for is to find and cancel the program that is holding things up. methinks it's actually the xwindow itself as in the lock state the mouse won't move. taking out the x-window will likely take all the running programs down too so the total option is likely getting through an orderly shutdown rather than a power off crash stop.

Hello. I think it's about X server. When you in second tty, you will need the help of

Code: Select all

top

or

Code: Select all

htop

. Write down the PID number of the process you want to kill (in this case, Xorg). Once you have the PID, run the below command in a root shell

Code: Select all

sudo -s

.

Code: Select all

kill -9 <PID>

. For example:

Code: Select all

kill -9 1234

.

[mike acker]

this helps a lot,-thanks

i have the top program; it works great.

one thing I've not found though--
how to I exit from the 2d terminal -- the one that starts in response to alt-F2 ?

I think startX will restart the X server after I kill it. But, having killed the x-server I might just as well issue a reboot command. at leat it should get me through an orderly shutdown.

[pylkko]

Type 'exit'. If you mean how to get back to first tty that you came from, then try another number. Usually the graphical interface runs on either F1 or F7.

After recovering from the crash, you should read all the logs to see if there are any error messages that can help you find the reason and fix it

[None1975]

this helps a lot,-thanks
I think startX will restart the X server after I kill it. But, having killed the x-server I might just as well issue a reboot command. at leat it should get me through an orderly shutdown.

You are welcome. Just in tty2 type exit. Then return to tty1 and startX.