Re: ifupdown writes to /etc... a bug?
The essence of the solution (as I see it now) is to ensure that
in future /var/run is rw, persistent until reboot, and available
independently of networking. I.e., it has to meet more stringent
criteria than dictated by the FHS.
On many systems, /var/run already meets these criteria.
Systems whose /var is on a network will have to be modified so
that /var/run is a symlink, both before and after the var fs is
mounted, to some directory, /run, that meets all three criteria.
/run could be a directory on the root fs (if the latter is rw)
or a tmpfs, or something else.
How to bring this change about is something that needs to be
discussed. Once systems have a /var/run that meets the new
criteria, maintainers can start moving runtime state files there
from places like /etc.
Miguel van Smoorenburg wrote:
> How about an implementation in sysvinit like this:
> - sysvinit includes /run
> - if the kernel supports it a shmfs is mounted on /run
> - otherwise if the kernel supports it a ramdisk is mounted on /run
> - the size of the shmfs/ramdisk can be set in /etc/default/rundirsize
> and is 128K by default. That will give you 94K and 128 inodes
> for an ext2 filesystem on a ramdisk and 128K for shmfs. That
> should be plenty, or not?
Many or most systems don't need /run; only those with a network-
mounted /var need it. Among the latter, many or most systems
don't need /run to be on a ramdisk; only those without a rw
local filesystem need it to be on a ramdisk.
I suggest that only those systems that need /run get /run.
And only those systems that need /run to be on a ramdisk get
/run on a ramdisk. This will minimize the number of systems
that are affected.
--
Thomas Hood <jdthood0@yahoo.co.uk>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Reply to: