[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /run support for wheezy?



On Fri, Apr 01, 2011 at 04:06:16PM +0200, Luca Capello wrote:
> Hi there!
> 
> On Fri, 01 Apr 2011 15:33:44 +0200, Roger Leigh wrote:
> > Patches filed against base-files and initscripts in #620157 and #620191.
> > Test packages here: http://people.debian.org/~rleigh/run/
> >   (tested in an amd64 kvm VM; it shouldn't toast your system by
> >   making it unbootable, but YMMV; test with caution.)
> [...]
> > I would also appreciate any testing, especially if you're using a
> > nonstandard setup e.g. tmpfs on /var/run and/or /var/lock.
> 
> Without having looked/tested your packages and being a bit naive, but
> given that tmpfs for /var/run and /var/lock can be configured through
> /etc/default/rcS, maybe it is more used than you think (and I would not
> completely call it nonstandard), thus it requires a bit more caution.

Not entirely sure what you mean here.  We detect and deal with this
sort of setup automatically.  I said "nonstandard" because TTBOMK this
feature is not widely used, and (I am given to understand) somewhat
broken.  I have tested this with manual mounts, and the code is working
for me.  Caution is definitely warranted though--that's why I'd like
more widespread testing so we can identify any special cases we need
to deal with in addition (if any).

If you're using RAMRUN/RAMLOCK, then you'll get the same setup, but
mounted under /run and /run/lock, with compatibility symlinks in place.
If you've set up the tmpfs mounts manually in /etc/fstab, we create
bind mounts on top since we can't create the symlinks.  It will again
automatically transition when you remove the fstab entries and reboot
(or you can just remove the entries, unmount the filesystems and rerun
the mountall init script).

AFAICT, we now cater for transitioning of all previously supported
configurations, as well as unsupported (manual) setups, though if you
manually set up stuff, you'll have to manually undo your work to clean
up properly (though you'll have a fully functional system at all times).

The logic is in run_migrate() in /lib/init/mount-functions.sh called
after mounting local filesystems in /etc/init.d/mountall.sh:

#
# Migrate a directory to /run and create compatibility symlink or bind
# mount.
#
run_migrate ()
{
	OLD=$1
	RUN=$2

	KERNEL="$(uname -s)"
	OPTS=""
	case "$KERNEL" in
		Linux|GNU) FSTYPE=none OPTS="-obind";;
		*FreeBSD)  FSTYPE=nullfs ;;
		*)         FSTYPE=none ;;
	esac

	# Try to remove if a directory.  Note this is safe because the
	# system is not yet fully up, and nothing is allowed to use
	# them yet.  If the user explicitly mounted a filesystem here,
	# it will be cleaned out, but this would happen later on when
	# bootclean runs in any case.
	if [ ! -L "$OLD" ] && [ -d "$OLD" ] ; then
		rm -fr "$OLD" 2>/dev/null || true
	fi

	# If removal failed (directory still exists), set up bind mount.
	if [ ! -L "$OLD" ] && [ -d "$OLD" ] ; then
		mount -t $FSTYPE "$RUN" "$OLD" -orw $OPTS
	else
		# Create symlink if not already present.
		if [ -L "$OLD" ] && [ "$(readlink "$OLD")" = "$RUN" ]; then
			:
		else
			ln -fs "$RUN" "$OLD"
		fi
	fi
}

#
# For compatibility, create /var/run and /var/lock symlinks to /run
# and /run/lock, respectively.
#
post_mountall ()
{
	# /var/run and /var/lock are now /run and /run/lock,
	# respectively.  Cope with filesystems being deliberately
	# mounted on /var/run and /var/lock.  We will create bind
	# mounts from /run and /run/lock to /var/run and /var/lock if
	# we can't remove the /var/run and /var/lock directories, or
	# else simply create symlinks.  For example, in the case that
	# the user has explicitly mounted filesystems on /var/run or
	# /var/lock, we bind mount over the top of them.  Where no
	# filesystems are mounted, we replace the directory with a
	# symlink where possible.

	run_migrate /var/run /run
	run_migrate /var/lock /run/lock
}


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature


Reply to: