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

Re: /run and read-only /etc

Jamie Wilkinson wrote:
> That is right!  The core of the matter is not whether
> filesystems need to be mounted over the network or not,
> but whether the parts of the filesystem you are attempting
> to write to are on the root filesystem or not.

The essence of /run/ had better not include that it be a
directory on the root filesystem, because the current proposal
is that it be possible for /run/ to be a RAM-based filesystem
on systems with read-only root media.

[... in another message:]
> Thus we don't need to compare /run to /var/run, but make /run available
> for the same purposes of the entirety of /var but only in the case that
> a required subdirectory of /var doesn't exist.

I balk at this.  IMHO we should call the new directory '/run/' 
if and only if we are going to use it for the same purposes
for which we use /var/run/.  If the new directory is to be a
whole parallel local var hierarchy then we should call it
something like '/lvar/'.  However, I don't think we need a
whole parallel local var.

> This works for the case that
> some programs need a /var/run and some need a /var/state
> and some need a /var/lib for their file;

/var/state/ is deprecated.

Files stored in the proposed new directory will be lost on reboot,
so it is not suited to be a "lib" directory.

> there will be so few programs actually
> using /run that there is no need to separate /run into further
> subdirectories for each of the /var subdirectories.

/var/ contains thirteen subdirectories on my system.  For which
of these is a guaranteed-to-be-local variant needed?  So far,
a case has been made only for "run".

With thanks for your /run/ patches...
Thomas Hood <jdthood0@yahoo.co.uk>

Reply to: