[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Reply to: