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

Re: ifupdown writes to /etc... a bug?



Emile van Bergen wrote:
> First I want to say that /run is very much OK to solve the problem at
> hand; it's just a pity that we decide to add a top-level direcory with a
> such a very limited purpose.

What we are limiting is the set of requirements that we impose on
the new directory.  We impose the minimal criteria required to
solve the problem at hand, leaving maximum freedom of implementation.

We aren't limiting a priori the purposes to which /run (or /whatever)
can be put, although initially it will only be used to solve the
problem at hand.  Which is good, because if we are going to put this
on a ramfs then we want to keep its minimum size down.

If /run is widely implemented in the future as a ramfs then the
benefits of a ramfs will be widely available.  That's great.  Maybe
it will become practical someday to require that /run be on a
ramfs.  But I don't think it is practical today.

So what's the problem at hand?  We need a place to store the runtime
state of the local system that is available earlier than /var/run is
available on some systems, and which can be made writable even when
/etc isn't, and (unlike /tmp) whose contents can be assumed to persist
after their owner processes exit.

It has been suggested that the new directory be called /var/run.
A disadvantage of this approach is that when /var is mounted this
directory becomes inaccessible, so mounting /var would have to be
done something like this
    copy /var/run somewhere (e.g., /tmp/run)
    mount /var
    clear out /var/run
    restore /var/run from /tmp/run
which looks pretty racy.

A big advantage of this approach is that it relieves people of the
burden of choosing between /run and /var/run on the basis of
how early the file is accessed.

Another approach that has the latter advantage but has no need for
race-vulnerable copying is to symlink /var/run to /run both before
and after /var is mounted.   Hmm ... yes this seems like the right
approach.  Or does this make /run too big?
    root@thanatos:~# du -s /var/run
    168     /var/run

Here is a list of files that people have suggested would go under
/var/run (i.e., /run).

/etc/adjtime
/etc/leapsecs.dat
/etc/motd
/etc/mtab
/etc/network/ifstate
/etc/resolv.conf
/etc/ioctl.save
/lib/modules/`uname -r`/modules.*
/var/run/
/var/lib/ntp/
/var/log/dmesg

Most of the /etc files listed above need to be split up into:
  * static parts to be stored in /etc
  * dynamic persistent parts to be stored in /var/lib
  * dynamic volatile parts to be stored in /var/run
E.g., /etc/resolv.conf should list only a default nameserver;
if ppp is brought up then the names of dynamically assigned
nameservers should be stored somewhere like /var/run/bind/resolv.conf.

I don't see why the following should moved under /var/run.

/dev/gpmctl
/dev/gpmdata
/dev/initctl
/tmp/.X11-unix/
/tmp/.font-unix/
/var/lock/

-- 
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: