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

Re: /run and read-only /etc

This one time, at band camp, Thomas Hood wrote:
>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.

The problem I have with that is a catch-22 situation with mount trying to
write to mtab, when the directory containing mtab doesn't yet exist.  Your
goal to make / mounted read-only will obviously need a solution to that.
I don't have an answer to that just yet.

>[... 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.

I encourage the use of /var for the purposes outlined in the FHS.  I only
provide /run as a catchall for those programs that have no /var available.
I do not expect there to be 13 or so subdirectories in /run to mirror /var.
I do not expect more than a handful of programs to need /run at all.  Off
the top of my head, the only programs needing /run are mount and the
sysvinit/login/pam combination, and the latter is certainly debatable.
>> 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.

I agree.  I was not aware that /var/state was deprecated (so excuse my
ignorance) though.  In that case, then the description for /run can
definitely compare itself to /var/run.

jaq@debian.org                               http://people.debian.org/~jaq

Reply to: