72

From the technical overview of Ubuntu 11.10 Oneiric:

Ubuntu 11.10 has migrated away from /var/run, /var/lock and /dev/shm and now uses /run, /run/lock and /run/shm instead (respectively).

  • I hardcode these paths in my applications, why is this change made to Oneiric?
  • What can I do to make my applications backwards- and forward-compatible? Is there a better way other than checking first for the existence of /run, and then /var/run?
Braiam
  • 67,791
  • 32
  • 179
  • 269
Lekensteyn
  • 174,277

5 Answers5

63

The intent is to reduce the number of tmpfs file systems. On 11.04, there are separate tmpfs file systems at /var/lock, /var/run and /dev/shm. If these directories were all under a single parent directory, then only a single tmpfs would be needed. It also provides an obvious location for further runtime state data that shouldn't persist over reboots.

Unless your application depends on canonical paths of files, your application should run without modification since the old locations will be symlinked to the new ones. The AppArmor policies are one case that does depend on the real path names, which is why it was mentioned specifically.

The following links should help explain the rationale:

Søren Løvborg
  • 3,394
James Henstridge
  • 41,136
39

  1. /run is a new cross-distribution tmpfs location for the storage of transient state files—that is, files containing run-time information that may or may not need to be written early in the boot process and which does not require preserving across reboots.

    Making the /run directory available brings us a step closer to the point where it is possible to use the system normally with the root filesystem mounted read-only, without requiring any clunky workarounds such as aufs/unionfs overlays.

    /run replaces several existing locations described in the Filesystem Hierarchy Standard:

    • /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]

    • /run also replaces some other locations that have been used for transient files:

    • /lib/init/rw → /run

    • /dev/.* → /run/*
    • /dev/shm/* → /run/*
    • writable files under /etc → /run/*

    (so you probably can expect these to move aswell).

    Source:debian release goals

  2. I would advice on creating a part in your software where you set these directories in variables, change your code to use these variables and then alter the variables based on the system it is used on (but I bet you knew that already).

Rinzwind
  • 299,756
  • 1
    What do you mean writable files under /etc. Those must all persist past reboot, right? That's just generic conf files. – Evan Carroll Apr 24 '12 at 16:43
  • 6
    Oh I see. Three files under /etc, /etc/lvm/cache/ /etc/mtab /etc/network/run/ifstate and soon /etc/adjtime. I suppose it was bad for them to be in /etc to begin with. – Evan Carroll Apr 24 '12 at 16:45
6

From what I have read, this was the original explanation given as to why /run was introduced. http://lwn.net/Articles/436012/

gotunandan
  • 61
3

You should not hardcode any of these /run paths!

  • Use /var/run, because a symlink will be in place to /run if applicable
  • /var/lock is the same as above
  • Don't hardcode /dev/shm ever, always use shm_open etc (the posix API)
ramslök
  • 12,620
3

Note: since /run introduction, small configurations might get troubles. My Ubuntu server is 256Mo RAM and /run is by default set to 49Mo.
At startup, it fills the filesystem until fullness.
Making changes in fstab does not operate to inscrease tempfs /run size. Neither does others procedures I found on gg.
I found the solution to add in init script : /etc/rc.local the line mount -t tmpfs tmpfs /run -o remount,size=85M to extends at startup.(The 85M is for my conf.)

korrident
  • 39