Bug#620870: debian-policy: Please add /run as FHS exception
Package: debian-policy
Version: 3.9.1.0
Severity: normal
Hi,
Please could you add /run as an exception to the FHS? I've attached
a patch with proposed text.
References:
#620191 - initscripts support for /run
#620157 - base-files provides /run
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976
- Fedora adoption
http://bugs.freestandards.org/show_bug.cgi?id=718
- FHS proposal
Summary:
/run is the new home for the contents of /var/run
/run/lock is the new home for the contents of /var/lock
This is something we've wanted in Debian for many years, which
resulted in the compromise of creating /lib/init/rw. However,
Fedora, SuSE, Ubuntu and ourselves have proposed to create /run
as a temporary filesystem available from early boot to replace
/lib/init/rw, /var/run and /var/lock. The above bugs are the
Debian implementation.
In the attached patch I have documented /run as an FHS exception
along with a brief rationale in the footnote, and also updated the
notes for init scripts to reflect the change. Note that I've put
the change in present (rather than future) tense because this is
already adopted by other distributions, and the above bugs should
mean it will be adopted in Debian very soon as well.
If you would prefer to delay adding this until we actually have this
working in unstable, that's fine. I just wanted to make sure that
the change is documented correctly.
Many thanks,
Roger
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (550, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
debian-policy depends on no packages.
debian-policy recommends no packages.
Versions of packages debian-policy suggests:
ii doc-base 0.10.1 utilities to manage online documen
-- no debconf information
diff --git a/policy.sgml b/policy.sgml
index ec605c6..2fda857 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -6205,10 +6205,21 @@ install -m644 debian/shlibs.<var>package</var> debian/<var>package</var>/DEBIAN/
<item>
<p>
The following directories in the root filesystem are
- additionally allowed: <file>/sys</file> and
- <file>/selinux</file>. <footnote>These directories
- are used as mount points to mount virtual filesystems
- to get access to kernel information.</footnote>
+ additionally allowed: <file>/run</file>,
+ <file>/sys</file> and <file>/selinux</file>.
+ <footnote>The <file>/run</file> directory is a
+ replacement for <file>/var/run</file>, and its
+ subdirectory <file>/run/lock</file> is a replacement for
+ <file>/var/lock</file>. These changes have been
+ adopted by most distributions and have been proposed
+ for inclusion in a future revision of the FHS. Both
+ are expected to be temporary filesystems, whose
+ purpose is storage of ephemeral system state which
+ should not be preserved across reboot.
+ The <file>/sys</file> and <file>/selinux</file>
+ directories are used as mount points to mount
+ virtual filesystems to get access to kernel
+ information.</footnote>
</p>
</item>
<item>
@@ -6719,14 +6730,18 @@ test -f <var>program-executed-later-in-script</var> || exit 0
</p>
<p>
- <file>/var/run</file> and <file>/var/lock</file> may be mounted
- as temporary filesystems<footnote>
- For example, using the <tt>RAMRUN</tt> and <tt>RAMLOCK</tt>
- options in <file>/etc/default/rcS</file>.
- </footnote>, so the <file>init.d</file> scripts must handle this
- correctly. This will typically amount to creating any required
- subdirectories dynamically when the <file>init.d</file> script
- is run, rather than including them in the package and relying on
+ <file>/var/run</file> and <file>/var/lock</file> should be
+ symlinks to <file>/run</file> and <file>/run/lock</file>,
+ respectively, which are temporary filesystems whose
+ contents are not preserved across reboots. This
+ arrangement may also be satisfied through equivalent
+ means, for example bind or nullfs mounts. Because the
+ presence of files or directories in any of these
+ directories is not guaranteed, <file>init.d</file> scripts
+ must handle this correctly. This will typically amount to
+ creating any required subdirectories dynamically when
+ the <file>init.d</file> script is run, rather than
+ including them in the package and relying on
<prgn>dpkg</prgn> to create them.
</p>
</sect1>
Reply to: