How to investigate the cause for unresponsiveness on Linux?

Question

I apologize that the problem I'm writing about is not very concrete. I use KDE4 on Debian testing, and use KDE's file manager Dolphin very often, most of the time without problems. Recently, I suppose after a system update, Dolphin is often very unresponsive. This may happen directly at startup – a minute or so passes before the window comes up – it may also happen later after for some time everything has been fine. The window contents are no longer updated, it takes ages until a file is opened after it was clicked on, etc. A reboot sometimes makes the problem go away, but not for long. I thought it might have to do with optical drive access, but the problem stays even if there is no medium in the drive. – I don't have any mounted network file systems. There are also no other processes eating up CPU time and/or disk bandwidth.

Now, the question I'm asking is not about this particular problem with Dolphin, but this:

How can I generally deal with the situation that a program becomes unresponsive? Is there a standard strategy to find out what causes such a problem, so that 1) I might find a fix or workaround for myself and/or 2) be able to submit a useful bug report?

In this case, because I thought it might have to do with Dolphin trying to access certain files and hanging because there's some kind of block, I started dolphin under strace and tried to make sense of the messages. However, there are lots and lots of "errors" of type "EAGAIN (Resource temporarily unavailable)" or "ENOENT (No such file or directory)", most of which don't appear to represent a problem. The only thing I learned reliably is that even if Dolphin doesn't react to user input that does not mean that there isn't a lot going on in response to mouse movements and mouse clicks...

Is strace the right tool? If yes, what should I look for in its output? If not, what should I use instead?

Answer 1

Well, strace prints a list of system calls made by the program. It may be useful and educational to use it, but if you are not a programmer it may not be very practical.

htop

If what you want is to make poorly responsive system get back to working state, then one of the most useful programs I have found is htop. Basically it shows you real-time system usage in a terminal. You should read a bit about it - it is very well documented and quite a few articles have been published about it. You use it in a terminal, therefore if your desktop has frozen but if you can still log in your computer via ssh it works. E.g. from your windows machine via pUTTY. It gives you a list of processes and shows the most important information about them. With F6 you sort processes by specific resource usage (e.g. processor, memory, swap) and thus you can see which program is the resource hog. With F4 you can filter by program name - just start typing. F5 shows you process tree and likely will show you what files are open by your program. With F9 you can send whichever KILL signal you want to the program. Nice thing is - you can simply move up and down with arrow keys and press numbers to select options - you should experiment a bit to appreciate this.

My rule of thumb is - if the system has not hung so much that pressing Num Lock does not blink the NumLock light, then chances are that some simple investigations and - SIGHUP or SIGKILL from htop will bring it back to stability. If the situation repeats - then you can fill the bug report.