←back to thread

A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

(lowendbox.com)
150 points shaunpud | 3 comments | 29 Aug 25 02:39 UTC | HN request time: 0.663s | source
Show context
nrdvana ◴[29 Aug 25 04:29 UTC] No.45060203[source]▶
The third mitigating feature the article forgot to mention is that tmpfs can get paged out to the swap partition. If you drop a large file there and forget it, it will all end up in the swap partition if applications are demanding more memory.
replies(3): >>45060224 #>>45060756 #>>45061403 #
m463 ◴[29 Aug 25 06:10 UTC] No.45060756[source]▶
what swap partition?

I meant this sort of jokingly. I think have a few linux systems that were never configured with swap partitions or swapfiles.

replies(1): >>45060793 #
edoceo ◴[29 Aug 25 06:17 UTC] No.45060793[source]▶
I'm with you. I don't swap. Processes die. OOM. Linux can recover and not lose data. Just unavailable for a moment.
replies(3): >>45060941 #>>45061182 #>>45062028 #
marginalia_nu ◴[29 Aug 25 07:21 UTC] No.45061182[source]▶
The Linux OOM killer is kinda sketchy to rely on. It likes to freeze up your system for long periods of time as it works out how to resolve the issue. Then it starts killing random PIDs to try to reclaim RAM like a system wide russian roulette.

It's especially janky when you don't have swap. I've found adding a small swap file of ~500 MB makes it work so much better, even for systems with half a terabyte of RAM this helps reduce the freezing issues.

replies(2): >>45061255 #>>45061577 #
mnw21cam ◴[29 Aug 25 08:26 UTC] No.45061577[source]▶
Install earlyoom or one of its near-equivalents. That mostly solves the problem of it freezing up the system for long periods of time.

I haven't personally seen the OOM killer kill unproductively - usually it kills either a runaway culprit or something that will actually free up enough space to help.

For your "even for systems with half a terabyte of RAM", it is logical that the larger the system, the worse this behaviour is, because when things go sideways there is a lot more stuff to sort out and that takes longer. My work server has 1.5TB of RAM, and an OOM event before I installed earlyoom was not pretty at all.

replies(4): >>45061814 #>>45062169 #>>45062516 #>>45064246 #
1. natebc ◴[29 Aug 25 11:01 UTC] No.45062516[source]▶
it's anecdata but I've had the linux OOM Killer take out OVS (Open Virtual Switch) on a kubernetes node several times.

Made me really not mind having a little swap space setup just in case.

replies(1): >>45062620 #
2. marginalia_nu ◴[29 Aug 25 11:17 UTC] No.45062620[source]▶
OOMKiller, as far as I understand it, will just pick a random page, figure out who owns it, and then kill that process, repeating until enough memory is available. This will bias toward processes with larger memory allocations, but may kill any process.
replies(1): >>45062752 #
3. menaerus ◴[29 Aug 25 11:41 UTC] No.45062752[source]▶
> If it ever becomes necessary for the OOM Killer to kill processes, the decision of which processes to kill will be made based on something called the OOM score. Each process has an OOM score associated with it.

> Every running process in Linux has an OOM score. The operating system calculates the OOM score for a process, based on several criteria - the criteria are mainly influenced by the amount of memory the process is using. Typically, the OOM score varies between -1000 and 1000. When the OOM Killer needs to kill a process, again, due to the system running low on memory, the process with the highest OOM score will be killed first!

https://learn.redhat.com/t5/Platform-Linux/Out-of-Memory-Kil...