In article <[EMAIL PROTECTED]>,
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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
