Bug#692559: Debian-init-diversity Digest, Vol 3, Issue 63

Roger Leigh rleigh at codelibre.net
Sat Dec 29 20:12:56 GMT 2018

On 29/12/2018 18:36, 
debian-init-diversity-request at chiark.greenend.org.uk wrote:
> Regarding RAMTMP, I am not sure whether it is actually useful. Really,
> if you want /tmp in tmpfs, just add entry into /etc/fstab. There should
> be one, and only one oblivious way to do it.

RAMTMP was added primarily for completeness.  If you read mount_tmp in 
mount-functions, you'll see that there are circumstances where we 
override it under certain conditions, e.g. read-only root fs or lack of 
space on root fs.  These mitigations are intended to allow booting on a 
system which would otherwise be broken due to the lack of a functional /tmp.

In general, the tmpfs handling in the initscripts was deliberately 
intended to allow direct configuration in /etc/fstab, which takes 
precedence over the /etc/default/tmpfs settings.  The reason for the 
default settings was to expose some of the variables used in the scripts 
which were useful to configure all of the standard tmpfs filesystems. 
This includes all the size limits.  Unlike for fstab (which does allow 
absolute size or percentage), here you can compute the limits on the fly 
based upon the system memory and whatever other factors you desire.

It's not expected that this will be commonly used, but it's there for 
those that wish to safely use multiple tmpfs filesystems with strict and 
intelligently-set limits, with no chance of OOMing the system by 
accident or malicious intent.


More information about the Debian-init-diversity mailing list