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 <email@example.com>