Re: Moving /var/run to a tmpfs?
[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.
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. This issue has been discussed here on the list a few
months ago, without any conclusion being reached. I do not want us to
release etch with a boot system unable to handle detected hardware
properly, so I decided to fix this now. Also, it is useful to make it
easier to set up stateless workstations using Debian (aka diskless
machines ala LTSP), and storing state information in a RAM file system
make this a lot easier.
/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. The only problem I have found so
far is with packages failing to create the directories they use in
/var/run/. These will break when this change is done. But there are
not very many such packages, because /var/run/ as tmpfs is supposed to
be a supported configuration, and most packages have been fixed
already to handle it.
We could of couse create /lib/init/rw/ or similar (/run, /lib/run, etc
have been proposed too), and ask packages like ifupdown to store their
state there, but I believe that is a bad idea because /var/run/ is
specified to be the location for runtime state information, and
creating another location for the same purpose is just increasing the
complexity without much gain.
I guess we can also add code during halt and reboot to store the
directories present in /var/run/ somewhere on / for mountkernfs.sh to
find and use it to recreate the directory structure, but I believe
that is a guaranteed way to fill /var/run/ with cruft, and recommend
against it. After all, it is not very hard to do the equivalent of
'[ -d /var/run/mydir] || mkdir /var/run/mydir' in the programs that
want a subdir in /var/run/.
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.
Friendly,
--
Petter Reinholdtsen
Reply to: