If /tmp runs out of space, it blocks various important things and can lead to a disaster. With the recent introduction of tmp-on-tmpfs feature, this problem became quite common. One of possible solutions how to mitigate the problem would be to watch the available space and increase the tmpfs size if needed (and if possible). Taking inspiration at bug #858265 comment #13, a swap file could be autoprovisioned then /tmp remounted to make use of the freshly added virtual memory.
Or whatever makes /tmp run out of space use /var/tmp instead...
(In reply to Jóhann B. Guðmundsson from comment #1) > Or whatever makes /tmp run out of space use /var/tmp instead... there's plethora of bugs filed for that (which reminds me that I forgot to put mine on the tracker ... fixed) however, some programs won't write to /var/tmp so taking care about /tmp still makes sense - or, aren't you trying to say that everything should write to /var/tmp and we can drop /tmp altogether?
(In reply to Karel Volný from comment #2) > (In reply to Jóhann B. Guðmundsson from comment #1) > > Or whatever makes /tmp run out of space use /var/tmp instead... > > there's plethora of bugs filed for that (which reminds me that I forgot to > put mine on the tracker ... fixed) > > however, some programs won't write to /var/tmp Which ones and why is that? so taking care about /tmp > still makes sense - or, aren't you trying to say that everything should > write to /var/tmp and we can drop /tmp altogether? What I'm saying is that if an program is writing to /tmp in 100MiB between reboots then it should write to /var/tmp instead. And I as administrator do not want any auto provisioned swap files or otherwise to surprise me and causing me a headache I would rather choose to mask tmp.mount. If this boils down to this causing trouble in vm's we could easily add "ConditionVirtualization=no" to tmp.mount unit ( or admins manually overwriting it ) but I would think we would need to get the opinions from at least the xen/qemu/kvm maintainers before defaulting to that in the distribution
+1 for this RFE. There are still hundreds of Fedora packaged programs which could potentially fill in the all available tmpfs space. It would be theoretically possible to fix all of them but not practically. Saving the users from having unresponsive system for a cost of enabling the swapping make very good sense for me. Keeping current state means punishing users for inattention of developers to the /tmp on tmpfs change. What is wrong on using the defensive approach? If we want to catch the remaining cases when program should write into /var/tmp instead of /tmp there are many other ways ho to do that aren't they?
Well, like on any file system we should have quotas on tmpfs, which is the only safe way to handle this. Just increasing the size constantly doesn't solve anything.
So, please understand that the size limit on /tmp is a limit, little else. A limit that is constantly bumped as usage increases is hence no limit at all. Hence I am pretty sure this request is not a good idea. It would defeat the very purpose of the limit to adjust it dynamically.