I am running Ubuntu Desktop 15.10 on my machine with 4 GB of RAM and 4GB of swap. My understanding of Linux was, when it starts to run out of RAM, it will start killing processes to get some RAM back, and supported by this other question.

What I am observing is, when the system runs out of RAM, it just freezes. Mouse and keyboard inputs stop working. For experiment to figure out will Kernel try to recover from such state, I left system in such a state overnight, but it didn't recovered.

Is in the desktops the behavior is altered? Why the system not killing applications to free up space. Is there some setting which needs to be enabled/disabled.

The applications running are very standard, browser, mail client, terminal and music player etc.

UPDATE: free -m output when system is running fine is:

total       used       free     shared    buffers     cached Mem:    
3271         3145       126      432         32        694
-/+ buffers/cache:       2418        853 

 Swap:         7503       1424       6079

I have increased swap (7+ GB now), to prevent frequent freezing of the system.

  • I’ve observed the killing of processes, I forget how that feature can be disabled, the only thing I recall is that users would adjust the swappines. Perhaps it matters, which processes are using the most memory, and which processes are hanging.
    – j0h
    Commented Feb 26, 2016 at 4:58
  • Would you be able post a free -meither in normal conditions, and when when the graphical interface is hosed? Commented Feb 26, 2016 at 13:58

1 Answer 1


It's hard to diagnose exactly what is going on because we don't have any real diagnostic information. But memory is a resource that is provided to processes that need it. If the system no longer has so-called physical memory to provide opon request, it has some options.

A typical solution is to use swap as virtual memory. A system can then get into a state where it is spinning on swap, spending more time managing dwindling memory and swapping things in and out than anything else.

But things won't be frozen, and the kernels still has its own reserved resources. But things will be really slow.

What you are describing is something different, though. It sounds like the system gets into a heavy resource allocation mode and then freezes. That is, there is no more running kernel, so nothing the kernel would do to mitigate resource contention can be done.

This might be an indication of a hardware problem (though I suppose it could be a kernel bug). That is, the heavy resource allocation cycle causes the hardware to fail. You could just have a bad stick of RAM or some other flaky hardware problem that only surfaces on heavy load.

I suppose most Linux systems these days have, or can easily get, a memtest option in the system startup menu. You could try that and see if you can reproduce it just with a heavy memtest run.

Another datapoint is to find out if the system is still alive in some manner. The local GUI might be locked up or busy, but the system still able to answer to pings or even accept remote logins. The next time it happens, try to access this host from another host. Even if it is slow to reply to pings or remote login attempts, even to the point of timing out, this will be a different response if the system is completely unresponsive.

This has been covered before on another SE, which may make this answer a duplicate. Mods should feel free to delete this one if this is the case.

  • The technical term of what you describe in the first middle of your answer is en.wikipedia.org/wiki/Thrashing_(computer_science) ; and I do believe the thing can get as pretty bad as freezing. It is not a given the kernel will always recover on its own from resource exhaustion. There actually counter-methods more or less successful to fight these situations, however for that I will have to add an answer. Commented Feb 26, 2016 at 7:58
  • I'm know the term, but I was trying to stay away from jargon and address the problem at hand. In all my years I've never seen a Unix-style system, desktop or server or embedded, thrash so hard it appeared totally locked up. At least, not for hours and hours, as described here. However we don't have the evidence to support any hypothesis at the moment. A better answer would be how to instrument this Ubuntu install so we can gather the information we need when it happens again, or a way of finding out post-mortem whether the kernel was just spinning or totally hosed.
    – user156990
    Commented Feb 26, 2016 at 12:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .