I've been doing a bit more experimenting with this (creating OOM situations) and racking my brain from when I had to deal with a similar thing back in my Solaris days.
Even though I can't come to a definitive answer to the OP, there is one red herring that I'd forgotten about; tmpfs.
The router has ~250MB of memory. /tmp will use half that amount (~125MB) by way of tmpfs... sort of:
Code:
Filesystem Size Used Available Use% Mounted on
devtmpfs 124.8M 0 124.8M 0% /dev
tmpfs 124.9M 6.5M 118.4M 5% /tmp
However (and this is the bit I forgot
) the "Size" (and by implication "Available") reported by
df is
not the amount of storage currently available. It is merely a limit on the
maximum amount of storage that
may be used
if there is sufficient free memory.
So as we can see from the output of
free the router is already using ~192MB. Even accounting for the 6.5MB of files in /tmp there is no way that the available space is 118.4MB. [I even managed to recreate the OP's dnsmasq errors by constantly sorting a large file in memory and
df still reported /tmp as 90% available].
Code:
total used free shared buffers cached
Mem: 255700 196704 58996 0 3052 19064
-/+ buffers/cache: 174588 81112
So the unused memory is ~58MB (potentially ~80MB if it freed up all the buffers/cache).
So to sum up, all this proves is that you can't get any meaningful clues out of
df. The best you can do is look at
free.
Of course this still doesn't identify the original problem. But I suspect it's simply that the memory is over-committed. In my tests
free was still reporting 36MB of free memory but processes were still crashing with OOM errors.