lower the size limit for /tmp |
||
Issue description/tmp is a ramfs created here: /etc/init/pre-startup.conf: mount -n -t tmpfs -o nodev,noexec,nosuid tmp /tmp By default, the max size of a ramfs is 1/2 of total RAM, so about 1GB for a 2GB chromebook, etc. I've seen several cases where the system crashed mysteriously, typically during automated testing but also in the field, where the kernel had OOM panics to which a full /tmp contributed. We should consider reducing the maximum size to a smaller number, independent of total RAM. For instance 200MB. Unfortunately we're not collecting stats for usage of /tmp so we don't know if we will run into other problems by reducing its size. Also, the restriction could be unnecessary and annoying in a number of situations. (Maybe we should have an "OOM file killer" in addition to an "OOM process killer" :)
,
Oct 10 2016
This is in semi-jest of course, but the "OOM file killer" can also kill processes with large files open in /tmp. That'll teach them good. Still better than a panic. Maybe. If we wanted to REALLY punish them, the OOMFK would simply zero the file, then optimize the zero-blocks away. :) OK sorry.
,
Oct 10 2016
if you wanted to be forceful/evil, you should be able to truncate the file behind their back. something like: >/tmp/foo will truncate the contents of the foo file to 0 bytes immediately even if other processes have it open. but sending a signal would probably be more graceful and less likely to cause weird user facing behavior and crash/feedback reports.
,
Apr 6 2018
|
||
►
Sign in to add a comment |
||
Comment 1 by vapier@chromium.org
, Oct 10 2016