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

Request for testing: /run and initscripts

On Wed, Apr 13, 2011 at 01:23:04PM +0200, Adam Borowski wrote:
> On Wed, Apr 13, 2011 at 10:51:50AM +0100, Philip Hands wrote:
> > On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl <biebl@debian.org> wrote:
> > > I don't think symlinking /tmp to /run would be a good idea, as one could fill up
> > > /tmp (accidentaly)  pretty quick.
> > > If we want to make / ro, then a separate tmpfs for /tmp looks like a better idea
> > > to me.
> > 
> > While were about this, for installs where the users select multiple
> > partitions we currently create a separate /tmp partition.
> > 
> > This strikes me as suboptimal, since one could use the disk space
> > allocated to /tmp as extra swap and then allocate a tmpfs of that size
> > to be mounted on /tmp with no effect other than allowing the system to
> > have access to more swap than it would have otherwise had (of course,
> > that's probably more than it needs, so instead you could just save some
> > disk space that would otherwise be left generally unused by overloading
> > the swap usage with /tmp usage.
> > 
> > Therefore, in the multi-partition setup, I think we should also default
> > to having /tmp on tmpfs.
> Sounds like a great idea.  I'd extend it to any setups with a swap.
> Tmpfs is a lot faster than regular filesystems: it doesn't have to care
> about preserving the data's integrity after a crash and thus has no
> barriers, journaling, fsync().  When there's plenty of unused memory, the
> data will not ever touch the disk, too -- gracefully getting written out
> when there is a better use for memory it takes.  Since most files in /tmp/
> are very short lived, it's a good optimization.

I have now implemented this (though it's not the default).

I would very much appreciate it if anyone could take the time to
install the new initscripts and test it out.


Note that it is safe to test these out on live systems; I've
installed it on my amd64 and powerpc machines, and not had any
issues.  I did notice an unclean umount of /var in one case,
but I think this was due to messing around with mount --move
which messes up /etc/mtab when moving recursively (/run/lock
probably didn't get unmounted).  I've not seen that on any other

So, by default, you get (separate tmpfs mounts):


For additional safety and security, it's possible to mount everything
as separate tmpfs filesystems:


(RAMLOCK=yes, RAMSHM=yes, RAMTMP=yes).  This lets one have separate
size limits and mount modes for each mount.

Alternatively, it's possible to have everything on a single /run
tmpfs, including /tmp (excluding /lib/init/rw, which will be
removed soon):

/tmp → /run/tmp

(RAMLOCK=no, RAMSHM=no, RAMTMP=no).  Note that /tmp was symlinked
to /run/tmp prior to restarting, and /run/tmp was created by the
init scripts (mountkernfs).  The symlink needs creating by hand
should you wish to do this.  Having /tmp as a symlink can be used
whatever the setting of RAMTMP, so you could have a tmpfs mounted
on /run/tmp if you chose.

In all these cases, these links were automatically created:
/dev/shm → /run/shm
/var/run → /run
/var/lock → /run/lock

The default size and permissions were set as proposed earlier in this
thread; there's still time to adjust or remove those depending upon
what the general consensus is.  We could also make not mounting
/run/shm the default, so that it's shared with /run by default; users
who need a dedicated large /run/shm could then enable this at their
discretion using RAMSHM and SHM_SIZE.

I would be very grateful to anyone who can take the time to install
the new initscripts and try it out.  It should set up bind mounts
of /var/run, /var/lock and /dev/shm to their locations in /run on
installation, and then set up the tmpfs filesystems properly and
do the conversion to symlinks on reboot.

Note that I did discuss doing this migration all in postinst using
mount --move with mbiebl, but it's unfortuntately linux-specific
and has some race conditions between moving and setting up the
symlinks (which may or may not be acceptable).  This patch errs on the
side of caution and ensures that the directories being moved are
available at all times, and that the code works on all architectures.

Also note that the move of /dev/shm to /run/shm might require the
selinux stuff tweaking.  This might require a change in one of the
selinux packages.  But I know little about selinux.

One oddity I noticed was that /etc/default/rcS is not a conffile,
making it difficult to add new options on upgrade since it's only
copied once on initial install.  Does anyone know why this is the
case, and would it be a problem if I made it into a conffile in
order to add the new RAMSHM and RAMTMP options (and remove RAMRUN)?
I've worked around this by setting defaults if unset in
/lib/init/vars.sh, but it might be nice to be able to update the
configuration as well so the current options are visible to the

So other than choosing sensible defaults for /etc/default/rcS and
/etc/default/tmpfs, I think this is ready to be deployed.

Many thanks,

  .''`.  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: