[HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
dledford at redhat.com
Mon Nov 29 21:43:00 UTC 2010
On 11/23/2010 04:32 PM, Lennart Poettering wrote:
> On Tue, 23.11.10 16:12, Doug Ledford (dledford at redhat.com) wrote:
>> On 11/23/2010 03:48 PM, Lennart Poettering wrote:
>>> I hereby want to let everybody know that in the next days I will turn on
>>> /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
>>> with the following accepted F15 feature:
>> Will the tmpfs mounts be available in the initramfs, or only on the
>> running system?
> Since /var/run is a subdir of /var which might be separate file system
> it is difficult mounting /var/run before /var. That means that it won't
> be available in the intird.
> (Yes, one can do stuff with show-through mount hierachies, that would
> allow replacing /var later on, but I am not a fan of such hackery.)
Hackery is in the eye of the beholder.
> Also note that by now it's somewhat standard that code that needs to be
> run as part of early boot creates a subdir in /dev, such as /dev/.udev
> or /dev/.systemd. Not super-pretty, but I guess it's too late to
> complain about that.
Those places all exist *because* no one took the time to create an
initrd managed writable /var/run or /var/lock. Using their existence to
justify continuing down a path that places files where they don't belong
is faulty logic. I took a *major* beating by the upstream mdadm
maintainer over the fact that we are putting files in /dev/ that don't
belong there. And he's right, we *shouldn't* be putting those files
there. Continuing a band aid hack because someone did it initially is
not the right course of action.
> Ideally the FHS would have never specified that /var/run and /var/lock
> would lie beneath /var, but I guess that's too late now.
One failed specification isn't really a good reason to justify creating
a de facto second failed specification.
Doug Ledford <dledford at redhat.com>
GPG KeyID: CFBFF194
Infiniband specific RPMs available at
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101129/6551e755/attachment-0001.bin
More information about the devel