# free RAM exhaustion & system freeze

## KarlisRepsons

All,

using and experimenting with a system of only 1GB RAM, which operates similar to tinhat (OS is in RAM!), I've learned that everything I need is done well except for doing fsck.ext3 on a 1TB filesystem. That kind of operation requires having some extra swap or the whole system freezes. I've experienced cases when some process goes out of RAM and gets terminated by kernel, but why can't kernel just terminate fsck? Any idea?

----------

## BitJam

 *KarlisRepsons wrote:*   

> ... why can't kernel just terminate fsck?

 

Terminating fsck can fsck up the file system.

----------

## KarlisRepsons

 *BitJam wrote:*   

> Terminating fsck can fsck up the file system.

 

So do you mean that there is some sort of list of processes, which won't get terminated by kernel even if that can end with a total system freeze?

----------

## Veldrin

no - he means you could wreck your filesystem be killing fsck.

----------

## Jazz-KP

 *KarlisRepsons wrote:*   

> 
> 
> So do you mean that there is some sort of list of processes, which won't get terminated by kernel even if that can end with a total system freeze?

 

It's possible to exclude processes from OOM killer's list via /proc/, but I don't think it's used anywhere. More likely something serious like 12309 happens before OOM killer may actually kick in. Maybe system starts to run short on disk buffer or something else. From my experience, system doesn't just freeze when you start to "run out of memory", it starts losing responsiveness over time (if you don't really care about fsck choking on 1 TB of your data, you can run it with watch uptime on a second terminal)

Even if you have enough ram for everything, it's always good idea to set up a swap partition with low swappiness. It will save your system in critical situations like this and won't actually use swap unless it's really needed.

----------

