/var/run and /var/lock contain small runtime files which need not to be kept around over a reboot, and hence are pointless to write to disk as it currently is done. Currently there's bootup code that explicitly empties these directories on boot. If we move these two directories to tmpfs this wouldn't be necessary anymore, simplifiying boot-up, making things less fragile. One could also argue that it might make things faster since it gets rid of unnecessary write accesses to disk.

+

/var/run and /var/lock contain small runtime files which must not to be kept around over a reboot, and hence are pointless to write to disk as it is currently done. Moreover, there's bootup code that explicitly empties these directories on boot. If we move these two directories to tmpfs, this wouldn't be necessary anymore, simplifying boot-up and making things less fragile. One could also argue that it might make things faster since it gets rid of unnecessary write accesses to disk, especially due to constant noatime related disk accesses.

== Benefit to Fedora ==

== Benefit to Fedora ==

Line 21:

Line 21:

== Scope ==

== Scope ==

−

systemd already contains the necessary support which is however not enabled in rawhide yet. This needs to be enabled.

+

systemd already contains the necessary support which is however not enabled in rawhide yet. This needs to be enabled. (DONE

−

Various .spec files need to add %ghost to the files/dirs in /var/run and /var/lock they currently own. [ ADD LIST HERE ]

+

Various .spec files need to to be modified to support [[Packaging:Tmpfiles.d | new tmpfiles.d packaging guidelines]]. The following packages are presumably affected as they own files in /var/run or /var/lock:

−

Some software might need patching, so that it is able to recreate its dirs/files in /var/run and /var/lock when they get lost on reboot. Since SUSE and Ubuntu already ship things with tmpfs on /var/run and /var/lock almost nothing should still require patching for this.

+

389-ds-base

+

abrt

+

Ajaxterm

+

amavisd-new

+

arm4

+

asterisk

+

avahi

+

balance

+

bdii

+

bind

+

bip

+

bro

+

bucardo

+

callweaver

+

Canna

+

clamav

+

clamsmtp

+

clement

+

cluster

+

cntlm

+

condor

+

conmux

+

ConsoleKit

+

couchdb

+

cups

+

cyphesis

+

cyrus-sasl

+

dansguardian

+

davfs2

+

dbus

+

ddclient

+

dirmngr

+

dkim-milter

+

dmapd

+

dmraid

+

dovecot

+

drbdlinks

+

dspam

+

ebnetd

+

ejabberd

+

exim

+

ez-ipupdate

+

fail2ban

+

fcron

+

filesystem

+

firebird

+

flumotion

+

freeradius

+

fwknop

+

gdm

+

gearmand

+

glibc

+

greylistd

+

groonga

+

hal

+

halevt

+

heartbeat

+

hostapd

+

httpd

+

icecast

+

initscripts

+

inn

+

iptraf

+

iscsi-initiator-utils

+

jetty

+

kde-settings

+

ldm

+

libgpod

+

libselinux

+

libvirt

+

lighttpd

+

lirc

+

lockdev

+

logcheck

+

ltspfs

+

lvm2

+

lxdm

+

mailman

+

mdadm

+

memcached

+

milter-greylist

+

mirrormanager

+

mldonkey

+

mod_fcgid

+

mod_mono

+

mongodb

+

monotone

+

mrtg

+

mumble

+

munge

+

munin

+

mysql

+

mysql-mmm

+

ndoutils

+

netdisco

+

net-snmp

+

NetworkManager

+

ngircd

+

noip

+

nrpe

+

nsd

+

nss-pam-ldapd

+

nufw

+

nut

+

openct

+

openldap

+

openstack-swift

+

openswan

+

openvpn

+

openxcap

+

ovirt-server

+

pacemaker

+

pam

+

pam_mount

+

pam_ssh

+

pathfinder

+

pcp

+

php

+

pki-ca

+

pki-kra

+

pki-ocsp

+

pki-ra

+

pki-tks

+

pki-tps

+

plymouth

+

pm-utils

+

polipo

+

portreserve

+

ppp

+

pptp

+

prcsys

+

prelude-manager

+

proftpd

+

psad

+

puppet

+

pvm

+

pyicq-t

+

qpid-cpp

+

quagga

+

radvd

+

redis

+

rkhunter

+

samba

+

sblim-gather

+

screen

+

setroubleshoot

+

slim

+

smokeping

+

spamassassin

+

spamass-milter

+

spectrum

+

sphinx

+

spice-vdagent

+

sslogger

+

system-config-printer

+

systemtap

+

tclhttpd

+

tetrinetx

+

tiger

+

tinyproxy

+

tmux

+

tog-pegasus

+

tokyotyrant

+

tor

+

tuned

+

udisks

+

unbound

+

up-imapproxy

+

util-linux-ng

+

util-vserver

+

uucp

+

vblade

+

vdr

+

vdradmin-am

+

vpnc

+

vtun

+

wesnoth

+

wpa_supplicant

+

xemacs

+

xen

+

xl2tpd

+

zabbix (Bugs filed: DONE)

−

The SELinux policy might need updates so that these dirs/files may be created on daemon startup.

+

Some software might need patching, so that it is able to recreate its dirs/files in /var/run and /var/lock when they get lost on reboot. Since SUSE and Ubuntu already ship things with tmpfs on /var/run and /var/lock almost nothing should still require patching for this. (To my knowledge: DONE)

−

The "find" command in /etc/rc.d/rc.sysinit that cleans up /var/run and /var/lock can go away.

+

The SELinux policy might need updates so that these dirs/files may be created on daemon startup. )DONE)

+

+

In some exceptional cases it might be necessary to add drop-in files to /etc/tmpfiles.d/ to some packages, if they are unable to create their own directories in /var/run on boot, or when the create more than one and those shall be labelled independently. See tmpfiles.d(5) for details (http://0pointer.de/public/systemd-man/tmpfiles.d.html). (DONE)

+

+

The "find" command in /etc/rc.d/rc.sysinit that cleans up /var/run and /var/lock can go away. (DONE)

== How To Test ==

== How To Test ==

Line 36:

Line 221:

Make sure that software that creates files/dirs beneath those two dirs still works fine. Mostly this means:

Make sure that software that creates files/dirs beneath those two dirs still works fine. Mostly this means:

−

a) the rpms can be installed properly

+

# the rpms can be installed properly

−

b) the rpms can be deinstalled properly, leaving no files in /var/run and /var/lock behind

+

# the rpms can be removed properly, leaving no files in /var/run and /var/lock behind

−

c) the software starts up properly.

+

# the software starts up properly.

== User Experience ==

== User Experience ==

Line 54:

Line 239:

== Release Notes ==

== Release Notes ==

−

/var/run and /var/lock are now mounted from tmpfs, and hence emptied on reboot. Applications must ensure to recreate their own files/dirs on startup, and cannot rely that doing this at package installtion will suffice

+

/var/run and /var/lock are now mounted from tmpfs, and hence emptied on reboot. Applications must ensure to recreate their own files/dirs on startup, and cannot rely that doing this at package installation will suffice. It is possible to use systemd's tmpfiles.d/ mechanism to recreate directories and files beneath /var/run and /var/lock on boot, if necessary. See tmpfiles.d(5) for details (http://0pointer.de/public/systemd-man/tmpfiles.d.html).

== Comments and Discussion ==

== Comments and Discussion ==

+

+

* Packaging Guidelines for use of tmpfiles.d to make the directories: https://fedorahosted.org/fpc/ticket/44

+

* Packaging Committee (ratified by FESCo) statement about not using %ghost for directories here: https://fedorahosted.org/fesco/ticket/525

Owner

Current status

Detailed Description

/var/run and /var/lock contain small runtime files which must not to be kept around over a reboot, and hence are pointless to write to disk as it is currently done. Moreover, there's bootup code that explicitly empties these directories on boot. If we move these two directories to tmpfs, this wouldn't be necessary anymore, simplifying boot-up and making things less fragile. One could also argue that it might make things faster since it gets rid of unnecessary write accesses to disk, especially due to constant noatime related disk accesses.

Benefit to Fedora

Simpler, more robust boot-up scheme. Possibly a little bit faster boot up. Since Ubuntu/Suse already do this this would bring Fedora more inline with the other distributions and minimize differences between the distros.

Scope

systemd already contains the necessary support which is however not enabled in rawhide yet. This needs to be enabled. (DONE

Various .spec files need to to be modified to support new tmpfiles.d packaging guidelines. The following packages are presumably affected as they own files in /var/run or /var/lock:

Some software might need patching, so that it is able to recreate its dirs/files in /var/run and /var/lock when they get lost on reboot. Since SUSE and Ubuntu already ship things with tmpfs on /var/run and /var/lock almost nothing should still require patching for this. (To my knowledge: DONE)

The SELinux policy might need updates so that these dirs/files may be created on daemon startup. )DONE)

In some exceptional cases it might be necessary to add drop-in files to /etc/tmpfiles.d/ to some packages, if they are unable to create their own directories in /var/run on boot, or when the create more than one and those shall be labelled independently. See tmpfiles.d(5) for details (http://0pointer.de/public/systemd-man/tmpfiles.d.html). (DONE)

The "find" command in /etc/rc.d/rc.sysinit that cleans up /var/run and /var/lock can go away. (DONE)

How To Test

Check /proc/mounts to verify that /var/run and /var/lock are now tmpfs.

Make sure that software that creates files/dirs beneath those two dirs still works fine. Mostly this means:

the rpms can be installed properly

the rpms can be removed properly, leaving no files in /var/run and /var/lock behind

the software starts up properly.

User Experience

A tiny bit of less disk accesses.

Dependencies

systemd

Contingency Plan

None necessary, revert to previous release behaviour.

Documentation

I don't think this needs much additional documentation, beyond what systemd already contains about this.

Release Notes

/var/run and /var/lock are now mounted from tmpfs, and hence emptied on reboot. Applications must ensure to recreate their own files/dirs on startup, and cannot rely that doing this at package installation will suffice. It is possible to use systemd's tmpfiles.d/ mechanism to recreate directories and files beneath /var/run and /var/lock on boot, if necessary. See tmpfiles.d(5) for details (http://0pointer.de/public/systemd-man/tmpfiles.d.html).