78

I just want to know where and how /run/lock and /run/shm can help our PC .

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              56G   13G   41G  24% /
udev                  983M  4.0K  983M   1% /dev
tmpfs                 396M  840K  395M   1% /run
none                  5.0M  8.0K  5.0M   1% /run/lock
none                  990M  164K  990M   0% /run/shm

1 Answer 1

106

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 ;)
3
  • +1. CentOS (RHEL) 7.* still use /dev/shm still now.
    – TuanNguyen
    Aug 21, 2016 at 6:22
  • 1
    Thanks for a nicely formulated answer. I'd like to point out an inaccuracy, tmpfs is not really in RAM and tmpfs is not ramdisk or even similar to ramdisk. This is a common misconception. tmpfs might be RAM based but it's hdd backed. RAM based the same as any file on a hdd through a page cache. To use tmpfs in a hope it's much faster or that it will not wake hdd from stand-by is a common mistake.
    – papo
    Jan 19, 2021 at 23:44
  • Here's a reference for tmpfs vs ramfs. Jan 1, 2022 at 17:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .