[HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide

Lennart Poettering mzerqung at 0pointer.de
Tue Nov 23 20:48:30 UTC 2010


I hereby want to let everybody know that in the next days I will turn on
/var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
with the following accepted F15 feature:


My current tests indicate that we will not run into too much trouble
with this and most things should continue to work just fine. However, of
course I run only a small subset of packages of the fedora archive on my
machine. So here's what might happen and which might need fixing over
the next weeks in various packages:

- Not all packages might be able to create their directory in /var/run
  on start-up. Since SUSE and Ubuntu have already been shipping systems
  with tmpfs on /var/run and /var/lock for quite a while I expect the
  number of packages that are incapable of doing this to be very
  small. If your software nonetheless fails witht this issue, then
  there are two options to fix this: a) patch the program in
  question, so that it is able to recreate the directories in
  /var/run, or b) ship a simple drop-in file for /etc/tmpfiles.d/ which 
  recreates these directories on boot. (see below)

- There might be permission problems, since the rpms might have set
  different perms on the subdirs of /var/run than the software itself
  might apply when starting up. In this case, a drop-in file in
  /etc/tmpfiles.d/ might  help. (see below)

- The SELinux policy might trigger AVCs and disallow creation of the
  dirs in question. In this case Dan will be of help of course, so make
  sure to file a bug. And I guess I don't need to mention this but
  temporarily falling back to permissive mode is a short-term workaround
  for this.

- In some cases daemons might want to create more than one file/dir
  below /var/run which are supposed to be labelled differently. In this
  case the daemon can either be modified to fix its labels up itself, or
  a drop-in file in /etc/tmpfiles.d/ might help (see below).

- Many .spec files currently own subdirs of /var/run. These need to be
  updated to %ghost those dirs only, so that the automatic removal of
  these files/dirs on boot doesnt cause rpm to complain. The list of packages
  which own such files/subdir you find on the aforementioned feature
  page. I will mass-file bugs against these packages later tonight,
  requesting the %ghosting of these entries. For more information on the
  %ghost directive in .spec files see this page:


Action items:

 a) Lennart will mass-file bugs regarding %ghost usage tonight

 b) Lennart will switch on /var/run and /var/lock on tmpfs either
 tomorrow or the day after tomorrow

 c) YOU need to edit your .spec file and place a %ghost where

 c) YOU need to test if you package still works, and if necessary file
 AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch
 it so that it is able to recreate these directories beneath /var/run on
 its own.

On /etc/tmpfiles.d:

This is a new feature of systemd, but which is apparently very much
liked by people outside of systemd, so this might actually find adoption
even on systems which will not adopt systemd any time soon, since it
actually is not specific at all to systemd. By dropping a simple
configuration file in /etc/tmpfiles.d you can ensure that volatile files
and directories are: a) created, deleted or emptied at boot b) their
permissions/ownership fixed c) its directory contents cleaned up in
regular intervals (a la tmpwatch) and d) it is properly relabeled at

As an example, here's how such a file might look like for the screen package
(name it /etc/tmpfiles.d/screen.conf):

d /var/run/screens 1777 root root 10d
d /var/run/uscreens 0755 root root 10d12h

This encodes that two directories are created under the listed names, with
automatic clean up after 10 days resp. 10 days and 12h. 

For more details consult the man page:


Thank you for your attention!


Lennart Poettering - Red Hat, Inc.
devel-announce mailing list
devel-announce at lists.fedoraproject.org

More information about the devel mailing list