Hello, i may be misunderstanding something, but to me, it looks like manually increasing the size of /tmp is a working workaround for several problems i am running into.
By now, there are some things, i will not even initiate before issuing: >> sudo mount -o remount,size=50G /tmp After this (temporary) change, the problems did vanish. Now, it did happen, that i simply forgot to issue this command, and swiftly problems reappeared. That is why i am looking for a more permanent solution. fstab has no entry concerning /tmp. After booting, mount gives this: >> tmpfs on /tmp type tmpfs (rw,nosuid,relatime,size=51200k) which is 1/1000 of the amount, that resolved my problems. As i understand, tmpfs does not eat up all that RAM, but uses the size argument as a max usage, while swapping to disk if memory pressure needs it. Apparently, a huge size argument would not be detrimental. Only i am uncertain about how to configure a better size, as obviously the system is setting up /tmp from outside of fstab. Furthermore, i find older fstab entries on the net with more arguments and i am not so sure, how important they are (noatime,nodiratime,mode=1777) Additional information: while i am still using oldstable (buster), i am in the process of catching up, remedying old unresolved issues as good as i can, before attempting to upgrade. One example problem: After kernel update, some vbox modules get recompiled, a compile that fails with a message saying, the modules would need to be signed on machines that are using EFI. (very confusing, as i went down that track first) But after providing a huge /tmp, the compile just succeeds. Does it make sense to interfere with the systems usage of /tmp? Yes, i have 128 GB of RAM, because i am using zfs and a lot of virtual machines, both needing huge amounts of RAM. How are the more experienced people among you handle /tmp ? Could i just benefit from your experience? thanks in advance DdB
