Re: /run vs. /lib/run

["Miquel van Smoorenburg" <miquels@cistron.nl>]

In article <[🔎] 20051222064207.GC6455@localhost.localdomain>,
Anthony Towns  <aj@azure.humbug.org.au> wrote:
>On Thu, Dec 22, 2005 at 01:37:11AM +0000, Miquel van Smoorenburg wrote:
>> This works at least on 2.6. [...]
>> This means that /var/run is always writable.
>
>That's really quite nice. I wonder if requiring 2.6 is even much of a
>problem -- 2.6.0 came out two years ago already and will be three by
>the time etch is released, after all; and I assume the Hurd can deal
>with this sort of issue trivially.

Well, it appears there's MS_MOVE support in 2.4 too, since 2.4.19.

>If "tmpfs swaps out" isn't enough to deal with screen and similar apps's
>use of /var/run, it might be worth just moving them to /var/lib anyway.

Well actually, perhaps we should not even use mount --move. Just
copying the files is enough:

	cd /var/run
	( cd /; mount -a )
	if ! [ . -ef /var/run ]
	then
		cp -a . /var/run
		rm -rf ./*  # (probably not needed)
		umount -n -l .
	fi
	cd /

I tested this and it works fine. It's also a better solution, since
several packages contain directories in /var/run and ofcourse
they expect them to still exist after a reboot.

There's still a problem here - if /var/run is not overmounted,
how do you copy the contents of the current /var/run tmpfs
into the /var/run underneath ?

Perhaps something like this instead:

	cd /var/run
	( cd /; mount -a )
	mount --move . /var/lib/earlyrun
	cd /
	cp -a /var/lib/earlyrun/. /var/run
	umount -n -l /var/lib/earlyrun	# we could try a few times
					# without -l first to give
					# daemons using early /var/run
					# time to realize what happened

There are 2 conditions for programs using "early /var/run",
if they are running as a daemon (eg bootlogd):

1. Don't chdir into /var/run
2. Every so often (before every write), check if open file
   handles for files in /var/run still correspond to the
   actual file - compare fstat() and stat()

For things like pidfiles, resolv.conf, mtab etc it will just work.

The only thing is - this won't work for Debian/kFreeBSD. Someone
needs to write MS_MOVE support for the kFreeBSD kernel, I guess :)

Mike.