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

Re: Moving /var/run to a tmpfs?

On Sun, Sep 17, 2006 at 12:56:47AM +0200, Petter Reinholdtsen wrote:

> [Steve Langasek]
> > However, that's not the same thing as saying it's ok for sysvinit to
> > *make* /var/run a tmpfs on the admin's behalf.  I think it's pretty
> > clear that this violates the letter of the FHS, and such a change
> > needs to be considered carefully.

> I fail to see how it violates the letter of the FHS.  It is as far as
> I can see unspecified what kind of file systems will be used, and also
> if directories will persist across boots.

   Files under this directory must be cleared (removed or truncated as
   appropriate) at the beginning of the boot process. Programs may have a
   subdirectory of /var/run [...]

It is clear /to me/ from the juxtaposition of these two sentences that the
FHS intends for programs to be allowed to create such subdirectories without
them being removed at the beginning of the boot process.  It is also clear
that this is how many maintainers have understood it, because as you
yourself have noticed, there are many packages that assume they can ship
directories in /var/run and have them remain available after reboot. :)  The
question is not whether we fix our packages to work sensibly when /var/run
is a tmpfs -- I agree that we should -- but what the consequences are for
*third-party* packages that are written with this same understanding of the

> The reason I believe it is important to have some writable file system
> available at the very beginning of the boot is that there are programs
> running when kernel modules are loaded by udev that need a place to
> store state information.  At the moment, there is no location to do
> that, and strange things can happen when the coldplug events happen
> early in the boot.  To fix it, some tmpfs area need to be mounted in
> mountkernfs.sh.

> /var/run/ is the natural place to store state information that should
> be cleared at boot time, so I decided to use that as the tmpfs
> location.  It sure helped to notice that Ubuntu already had patches to
> do this, and that these patches are structured in a way that should
> work with upgrades and also make sure /var/run/ isn't shadowed when
> /var/ is mounted later in the boot.

And is this technique safe with the 2.4 kernels that our userspace needs to
continue supporting in etch for upgrade purposes?

> All in all, I believe the right solution for Debian is to make
> /var/run/ a tmpfs directory by default, and modify the packages using
> subdirectories there to create it before they use it instead of when
> the package is installed.

I definitely do not agree that we should be making /var/run a tmpfs
directory by default for etch.  Indeed, I think we should push for
clarification of the FHS on this point before making any such change,
because the FHS is not just for the benefit of packages' interactions with
one another -- it's also for the benefit of third-party packagers and to
give users a set of assumptions they can depend on when interacting with
their own systems.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: