Re: Moving /var/run to a tmpfs?

[Bruce Sass <bmsass@shaw.ca>]

On Sat September 16 2006 16:56, 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.
>
> 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.

Sounds fine, if one has enough RAM to spare.

How big can /var/run get? Could such a change limit the usefulness of 
low mem systems? Is it feasible to create a tmpfs based /var/run during 
boot then move its contents to a disk based /var/run (if that is the 
admin's the preference) when /var becomes available?


- Bruce