Bug 990988 - RFE: increase tmpfs size for /tmp on demand
RFE: increase tmpfs size for /tmp on demand
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 873273 F18TmpOnTmpfs
  Show dependency treegraph
 
Reported: 2013-08-01 07:00 EDT by Karel Volný
Modified: 2013-10-13 15:23 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-13 15:23:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2013-08-01 07:00:26 EDT
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.
Comment 1 Jóhann B. Guðmundsson 2013-08-01 07:13:05 EDT
Or whatever makes /tmp run out of space use /var/tmp instead...
Comment 2 Karel Volný 2013-08-01 09:32:40 EDT
(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?
Comment 3 Jóhann B. Guðmundsson 2013-08-01 11:05:08 EDT
(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
Comment 4 Ondrej Hudlicky 2013-08-01 11:31:36 EDT
+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?
Comment 5 Lennart Poettering 2013-08-06 10:31:02 EDT
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.
Comment 6 Lennart Poettering 2013-10-13 15:23:45 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.