Ubuntu – How to resize /run (to make /run/shm bigger) properly – and where is it’s’ size set

Instead of /dev/sdc1, you could use the UUID for the disk. Use the command sudo blkid to find it, and then write UUID=[uuid here] like the other entries. That might help fstab find it better.

Short answer: they store temporary system files, including device locks and memory segments shared between different processes. Don't worry, they usually use a fraction of their "size" shown by df

1. /run is, in general, a temporary filesystem (tmpfs) residing in RAM (aka "ramdisk"); its meant for storing "temporary" system or state files which may be critical but do not require persistence across reboots.

   • /run is actually a fairly new innovation, and was added a couple of years ago to replace the multiple tmpfs's that used to be created (including /var/lock and /dev/shm) with a single unified root tmpfs.
   • The main locations /run replaces are:

   /var/run → /run
   /var/lock → /run/lock
   /dev/shm → /run/shm [currently only Debian plans to do this]
   /tmp → /run/tmp [optional; currently only Debian plans to offer this] 
   

2. /run/lock (formerly /var/lock) contains lock files, i.e. files indicating that a shared device or other system resource is in use and containing the identity of the process (PID) using it; this allows other processes to properly coordinate access to the shared device.

3. /run/shm (formerly /dev/shm) is temporary world-writable shared-memory. Strictly speaking, it is intended as storage for programs using the POSIX Shared Memory API. It facilitates what is known as inter-process communication (IPC), where different processes can share and communicate via a common memory area, which in this case is usually a normal file that is stored on a "ramdisk". Of course, it can be and has been used in other creative ways as well ;)

4. Do not be alarmed about the size: importantly, many people running df -h and knowing that /run is backed by RAM are shocked that their precious memory is being "wasted" by these mysterious folders. Just like the Linux ate my RAM myth though, this belief is incorrect.

   • The size shown is only the maximum that may be used
   • It defaults to 50% of physical RAM
   • Only as much shown in the Used column is actually in use, which in the above screenshot is less than 1 megabyte total
   • You can use the ipcs -m command to verify that the actual shared memory segments used match up to the df summary, and also see which PIDs are using them
   • Like your regular RAM, /run is also eventually backstopped by your swap, so if you are using /run/shm for "faster" compile times, keep that in mind ;)