On Sun, May 27, 2012 at 1:20 AM, Canek Peláez Valdés <[email protected]> wrote: > On Sat, May 26, 2012 at 11:29 PM, Joshua Murphy <[email protected]> wrote: > [ snip ] >> Well, given that it's there, it cleans up after itself, and it avoids >> issues in the instance where /var isn't available early on, is there >> much reason _not_ to link /var/run and /var/lock over to their >> respective equivalents on /run? > > I use systemd, which was the one introducing both /run and /run/lock: > > http://lists.freedesktop.org/archives/systemd-devel/2011-March/001757.html > > With systemd, /var/run and /var/lock are bind-mounted to /run and > /run/lock respectively. /run uses in my laptop (regularly suspended, > with an uptime of 25 days) 8.8 megabytes, which I think is basically > nothing for my 4 gigabyte RAM. > > After more programs (dracut, plymouth) started using /run and > /run/lock, OpenRC implemented the same functionality; or so I read > somewhere, I haven't used OpenRC in a while. In theory, it should work > the same as with systemd.
I take that back; OpenRC doesn't bind-mount /run in /var/run. I ssh'd to a server running OpenRC, and /var/run is independent from /run. And still a regular directory, not a tmpfs. That's a shame. Given that udev uses /run (stable "old" version, 171-r6), OpenRC should use it too; there is basically no cost, and the gains are obvious. With systemd is automatic the bind-mounting of /run into /var/run. Perhaps a future version of OpenRC will use it? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
