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

Re: /run vs /var/run

On Mon, Dec 19, 2005 at 05:48:45PM +0100, Thomas Hood wrote:
> > Note the definition for /usr/lib is "Libraries for programming and
> > packages" and "/usr/lib includes object files, libraries, and internal
> > binaries that are not intended to be executed directly by users or
> > shell scripts." and /var/lib is "Variable state information" and "This
> > hierarchy holds state information pertaining to an application or the
> > system. State information is data that programs modify while they run,
> > and that pertains to one specific host."
> > 
> > Combining these two, and adding the "...needed to boot the system"
> > qualifier seems like it would perfectly cover the above requirements
> > and /run.
> Let me see if I have understood the argument.  Let's call the new
> directory 'R' for now.
> <attempt to paraphrase>
>    /lib is, like R, a directory required for programs needed
>    to boot the system and run commands in the root filesystem;
>    and /var/lib is, like R, a place where data is stored.
>    We just heard "lib" twice!  So /lib is the right place for R.
> </attempt to paraphrase>

"We just heard "lib" twice!" ? You either get to fairly summarise an
argument or mock it; don't try to do both at once.

The line of thinking is this: we would like to put everything in a
single namespace under /, but we can't for two reasons: one is that /
has to be small in some circumstances, so we use a separate namespace,
/usr, that doesn't have that limitation; the other is that it's better to
have separate read-only and read-write namespaces; so we put non-static
information in /tmp, and /var. But beyond that, /, /usr, and /var are
more or less the same -- hence /bin and /usr/bin, /lib and /usr/lib,
and /tmp and /var/tmp, in each case, both directories containing the
same sort of contents -- with the provisos that changing data goes in
/var/foo, large static data goes in /usr/foo, and we limit /foo to stuff
that's needed to boot or recover the system.

If the question is "what does /lib contain?" the answer, then, is "the
same sort of stuff that /usr/lib or /var/lib contains, but limited to
that necessary to boot the system".

> I don't think that an argument from the meaning of "lib" can get
> much traction because /lib, /usr/lib and /var/lib are so different.

They don't seem very different to me. /lib and /usr/lib both contain
static libraries. /usr/lib and /var/lib both contain subdirectories of
package specific data, split by the requirements of /usr and /var. /lib,
/usr/lib and /var/lib are all a good default place for random data that
people hadn't previously thought of.

> (I'll guess that these differences are there because:
> * /usr/lib contained both application code and application data
>   in the old days;

So did /etc. Unlike /etc, /usr/lib remains *designed* to contain
application code and data, currently. /lib in practice does the same
thing today: containing .so files, kernel modules, script fragments,
and terminal information.

> * When application data was removed from /usr/lib it was placed
>   in /var/lib, which missed the opportunity to choose a more
>   appropriate name such as '/var/data';

For a brief time, /var/lib was renamed to /var/state, as it happens;
it was renamed back when that proved unnecessarily cumbersome.

> * When /usr/share was split out of /usr/lib, no /share was split
>   out of /lib.  

That would be because it's no easier to share /share across different
machines than /usr/share, and because creating new directories in / is
a bad idea.

> But there are problems with this particular argument as I have
> paraphrased it (probably distorting it).  First, if we accept the
> reasoning steps then the conclusion ought to be that the right value
> for R is "/lib/lib".  What went wrong?  

You pulled a "lib" from nowhere -- following the theory the "right"
value for R in that case would be "<package>" or "misc". But that
doesn't help distinguish an early read-write namespace, and seems kinda
pointlessly pedantic. Afterall, if you're going to be that pedantic,
/lib already forbids non shared libraries and non modules, so clearly
/lib/run is unpossible.

> So if we add _another_ directory with the same supporting role as
> them then it should be, like them, in the root directory. 

Only if you also want to say "supporting directories of apps in /usr/bin
should be, like them, in /usr, thus /usr/var/...". And while you might
well say that, we don't.

> Second, we missed the fact that the
> function of R is more analogous to /var/run than to /var/lib, 

Actually we (I) deliberately ignored it; mostly because /var/run is a
subset of the functionality of /var/lib, and "needed for boot" doesn't
warrant breaking up the functionality like that. /lib/var would be the
obvious alternative, and more accurately indicate "variable data needed
early in bootup". *shrug*

> and so
> should have a basename of 'run' rather than 'lib'.  Hence R should
> be /run.

Heh. I'm shocked -- shocked!! -- by your conclusion.

> Briefly, if R is like /var/run except that it supports programs

In theory, R is exactly like /var/run, and should in fact be /var/run.
I'm not sure there actually are any situations where /var can't be mounted
as soon as it's necessary; that may mean doing an NFS mount before running
ifup; but that happens already if you've got an NFS mounted root fs, eg.

In any event, the /var/run -> /run argument is fine, except that you
*also* have to have a good argument why you can't just use an existing
directory in /.

> Here's another possible argument:
>    Putting R in /lib spoils the otherwise read-only
>    character of that directory.

Putting R in / spoils the otherwise read-only character of that
directory. *shrug*

On Mon, Dec 19, 2005 at 06:01:15PM +0100, Thomas Hood wrote:
> Anthony Towns wrote:
> > Developers have been known not to be completely familiar with policy,
> > but it's admins and upstream programmers that I'm particularly
> > thinking of.
> I don't see any problems arising from rampant /run use by _admins_.
> They are always free to do what they want with their systems.

Only in the sense that they're free to type "sudo mv /bin /Binaries"
and live with the fact they can't login. If /run is a tmpfs, putting
information that should be in /var will cause performance problems.
Accidently encouraging that by our choice of naming isn't good behaviour
on our part.

> As for upstream programmers, most of them can't use /run because
> their software doesn't run with root privileges.  

That is, pretty much everything that runs as a daemon, and that might
have otherwise used /var in general.

> I don't think that Debian would ever be accused of lacking zeal in
> enforcing its Policy.  :)

Please see the other thread on RC bugs not getting fixed...


Attachment: signature.asc
Description: Digital signature

Reply to: