The issue of where to put state information that needs to be stored
prior to the initialization of networking (or independently of
networking) has been discussed before. The longest discussion I can
recall was in the spring of 2003 and had the subject headings:
* ifupdown writes to /etc... a bug?
* /run and read-only /etc
* /run/, resolvconf and read-only root
As indicated by the last subject heading, the state-storage issue
is related to the issue of eliminating variable data from the root
filesystem so that the latter can be read-only. I created a web
page to summarize my views on this issue and in order to track the
development of resolvconf (now a mature package) and the removal of
variable files from /etc/.
http://panopticon.csustan.edu/thood/readonly-root.html
I won't summarize the whole discussion here. I will just say that
I see good reasons for adopting /run as a standard location for the
storage of state information that needs to be stored prior to the
availability of networking. I see no good reasons for not adopting
it. If /run is created as a standard location then of course I
will make resolvconf use that location. The only reason that
resolvconf currently uses /dev/shm is that the last time this was
discussed there was no consensus that /run should be created and
endorsed as a standard Debian directory. Using /dev/shm seemed
like a reasonable alternative, although using this location took
more work to debug than I expected.
One non-silly argument for not adopting /run as the standard
location was that using /run would (allegedly) violate the FHS.
However, it would NOT violate the FHS. FHS 2.2 contained language
that might reasonably be taken to rule out the use of any root
directories not already on the list, but, especially in light of
the fact that many distributions do create such directories for
special purposes, FHS 2.3 clarified this to:
Distributions should not create new directories in the
root hierarchy without extremely careful consideration
of the consequences including for application portability.
I spoke to Christopher Yeoh about getting explicit FHS endorsement
of /run and he said that so long as there is a justification for
creating the directory there is no reason why it shouldn't be
explicitly endorsed in the next version of the FHS.
At the present time I know of the following files which might
appropriately be kept in a subdirectory of /run/.
/etc/nologin
/etc/mtab
/etc/network/run/ifstate
/etc/resolvconf/run/*
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
