[HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide

Doug Ledford 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:
>>> Heya!
>>> 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:
>>> https://fedoraproject.org/wiki/Features/var-run-tmpfs
>> 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...
Name: signature.asc
Type: application/pgp-signature
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 mailing list