[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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]