Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)
Roger Leigh <firstname.lastname@example.org> writes:
> On Fri, Apr 15, 2011 at 04:41:56PM +0200, Goswin von Brederlow wrote:
>> Roger Leigh <email@example.com> writes:
>> > If it wasn't already clear, having /tmp as a tmpfs is a
>> > /configurable option/, and it is /not/ the default (except when
>> > root is read-only (ro) in fstab).
>> I hope you check the fstab first. If there is a entry for a non tmpfs
>> /tmp filesystem then that should be used. I'm assuming you do but just
>> to be sure...
> No, we don't check. It's up to the admin to configure their
> system properly. If there is an entry in in fstab, it'll be
> mounted on top of the tmpfs, so the system will be configured
> the way they asked, but there will be a hidden tmpfs mount.
> But they would have explicitly needed to set RAMTMP=yes to get
> into this situation.
> For new installs, where the default /etc/default/rcS files does
> set RAMTMP=yes by default, the fstab file will not yet contain
> any user-specific mounts. If they do want to manuall mount
> something on /tmp, then they simply set RAMTMP=no.
> Note this behaviour is exactly the same as existing practice for
> /dev/shm, /var/run and /var/lock.
Then I don't get your 'is /not/ the default (except when root is
read-only (ro) in fstab)'.
To me that reads like you will mount a tmpfs on /tmp if root is
read-only even if RAMTMP is not set. Which is wrong if the system has a
/tmp filesystem in /etc/fstab.
I already have a tmpfs for /tmp in my /etc/fstab and my root is
read-only. Does that then mean I do get 2 tmpfs mounted for /tmp, one
over the other?
Also mount -a (in mountall.sh) fails, and therefore the whole boot, if a
mountpoint already has something else mounted. If you unconditionally
mount a tmpfs on /tmp if root is read-only then you just made systems
unbootable that have /tmp in fstab. You do not get the behaviour you