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