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

Lennart Poettering mzerqung at 0pointer.de
Tue Nov 23 21:57:57 UTC 2010


On Tue, 23.11.10 22:44, Till Maas (opensource at till.name) wrote:

> On Tue, Nov 23, 2010 at 10:32:00PM +0100, Lennart Poettering wrote:
> 
> > 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.
> 
> This is the first time I read about using a subdir in /dev. Is there
> some inter-distro agreement about this? The last discussion I had with
> someone from debian revealed that they use subdirs in /lib for stuff
> that should be in /var according to the FHS but might be needed before
> /var is mounted.

Well it's not really inter-distro. It mostly inter-maintainers-of-
packages-that-are-involved-with-early-boot. I know that at least some
storage stuff also puts stuff there, as will most likely u-l-ng to place
meta information about mounts.

Yes, Debian has /lib/init/rw, and we shortly considered adopting that as
suggested default in systemd, but we decided not to do that since more
software was already using /dev/.foo/ than /lib/init/rw (which in fact
is used only by debian specific scripts afaik at this point), and we
didn't want to add yet another fs just for this purpose to the mix.

I talked to some Debian guys about this and they have ben thinking about
moving /lib/init/rw to /dev/.foobar/ too. 

I think everybody agrees that /dev/.foobar/ isn't particularly
pretty. But given that /dev is some kind of tmpfs these days this should
be fine.

I don't think it is really necessary to make /dev/.foobar/ some kind of
standard however. As the number of services involved with early boot and
which need runtime files like this is very limited it should be
sufficient to simply come to an agreement with the various maintainers
involved, which is a small group.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list