mounts not present in fstab. where are they?

Question

my debian system is using tmfs for a few things, notably /tmp

and it's using a rather small size for it. And it's nowhere to be found in my /etc/fstab

i guess i could just add the entry in fstab and it will take effect, but i'd really like to understand what is going on.

mount:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=219602,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=207432k,mode=755)
/dev/disk/by-uuid/xxx on / type ext4 (rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=414864k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,relatime,size=414864k)
/dev/md0 on /DATA type ext4 (rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)

fstab:

proc            /proc           proc    defaults        0       0
UUID=xxx /               ext4    noatime,errors=remount-ro 0       1
UUID=zzz none            swap    sw              0       0  
/dev/md0    /DATA   ext4    noatime,errors=remount-ro 0 0

I can understand /sys /proc /dev being kicked off by something else than fstab, and i can also understand the benefits of /tmp and /run being a fstmp... but where is that defined?

Where does those mounts come from?

Solution

/run is a catchall tmpfs in RAM for Debian, with the others (lock, etc.) being symlinks. By default, the size of the /run tmpfs is set to 50% of your physical memory.

/tmp is made a tmpfs only if RAMTMP=yes, or a read-only root filesystem is detected.

According to the Debian wiki, these are the steps for mounting /run, /tmp, etc., performed by initscripts and initramfs-tools:

Stage #1: Initial package install

• /run is created on package installation
• /var/run is bind mounted to /run
• /var/lock is bind mounted to /run/lock
• /dev/shm is bind mounted to /run/shm

This ensures that the /run hierarchy is present, but /var/run and /var/lock are still used for storing the files and directories accessed via /run.

Stage #2: After system reboot

• A tmpfs is mounted on /run
• (Optional) A tmpfs is mounted on /run/lock if RAMLOCK is configured
• (Optional) A tmpfs is mounted on /run/shm if RAMSHM is configured
• (Optional) A tmpfs is mounted on /tmp if RAMTMP is configured
• A symlink /var/run → /run is created (falls back to bind mount if symlink failed)
• A symlink /var/lock → /run/lock is created (falls back to bind mount if symlink failed)
• A symlink /dev/shm → /run/shm is created (falls back to bind mount if symlink failed)

Comments

[Celada]

I can see on a Debian system that there is /etc/init.d/mountoverflowtmp which is designed to mount a tmpfs on /tmp even when /etc/fstab doesn't call for one in case there is very little space available on /. It seems unlikely that this is what you are encountering (how much free space do you actually have in /?) but can you check for that? It is the only thing that I can see in the init scripts that could be responsible for that.

[gcb]

26Gb free on /. will check that script to see if there's more hints. thanks! EDIT: you're right... found this part "If root is read only, default to mounting a tmpfs on /tmp, unless one is due to be mounted from fstab." very weird behaviour... don't know why it would need /tmp before the fs checks and remount as rw.

[Celada]

Good catch on the read-only thing. That's funny. I should have thought the root would be remounted rw during execution of S35mountall.sh or earlier, which comes before S37mountoverflowtmp in sequence.

[grifferz]

What are you actually trying to do? Increase the size of the automatic tmpfs you get for /tmp? A writable /tmp is needed for lots of things so I can understand why it gives you a tmpfs for it if there isn't one already. /etc/fstab is far from the canonical place to list everything that will ever be mounted and has been for a long time.

[gcb]

what's RAMTMP? a kernel option during compile time? boot option? the linked wiki mentions it without further explanation, and a search only leads me to flamewars on bug reports if it should default to yes or no :)

[ish]

in /etc/default/rcS, the linked wiki says. That's where you'd switch it, if you wanted to...