[lxc-devel] [Lxc-users] lxc-start leaves temporary pivot dir behind

Michael H. Warfield mhw at WittsEnd.com
Thu May 13 10:58:05 UTC 2010


On Wed, 2010-05-12 at 23:18 +0200, Daniel Lezcano wrote: 
> Ferenc Wagner wrote:
> > Daniel Lezcano <daniel.lezcano at free.fr> writes:
> >
> >   
> >> Ferenc Wagner wrote:
> >>
> >>     
> >>> Daniel Lezcano <daniel.lezcano at free.fr> writes:
> >>>   
> >>>       
> >>>> Ferenc Wagner wrote:
> >>>>     
> >>>>         
> >>>>> Actually, I'm not sure you can fully solve this.  If rootfs is a
> >>>>> separate file system, this is only much ado about nothing.  If rootfs
> >>>>> isn't a separate filesystem, you can't automatically find a good
> >>>>> place and also clean it up.
> >>>>>           
> >>>> Maybe a single /tmp/lxc directory may be used as the mount points are
> >>>> private to the container. So it would be acceptable to have a single
> >>>> directory for N containers, no ?
> >>>>         
> >>> Then why not /usr/lib/lxc/pivotdir or something like that?  Such a
> >>> directory could belong to the lxc package and not clutter up /tmp.  As
> >>> you pointed out, this directory would always be empty in the outer name
> >>> space, so a single one would suffice.  Thus there would be no need
> >>> cleaning it up, either.
> >>>       
> >> Agree. Shall we consider $(prefix)/var/run/lxc ?
> >>     
> >
> > Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot
> > if /var/run is on tmpfs.  This isn't variable data either, that's why I
> > recommended /usr above.
> >   
> Good point. I will change that to /usr/$(libdir)/lxc and let the distro 
> maintainer to choose a better place if he wants with the configure option.

Are you SURE you want /usr/${libdir}/lxc for this?  Some high security
systems might mount /usr as a separate read-only partition (OK - I'm and
old school old fart).  Part of the standard allows for /usr to be an RO
file system.

Wouldn't this be more appropriate in /var/${libdir}/lxc instead?  Maybe
create a .tmp directory under it or .tmp.${CTID} or something?  Or,
maybe, something under /var/${libdir}/lxc/${CTID}/tmp instead?  /var is
for things that change and vary.  Wouldn't that be a better location and
you've already got control of the /var/${libdir}/lxc location, don't
you?

> >>> Now the question is: if rootfs is a separate file system (which
> >>> includes bind mounts), is the superfluous rbind of the original root
> >>> worth skipping, or should we just do it to avoid needing an extra
> >>> code path?
> >>>       
> >> Good question. IMO, skipping the rbind is ok for this case but it may
> >> be interesting from a coding point of view to have a single place
> >> identified for the rootfs (especially for mounting an image). I will
> >> cook a patchset to fix the rootfs location and then we can look at
> >> removing the superfluous rbind.
> >>     
> >
> > I'm testing your patchset now.  So far it seems to work as advertised.
> >   
> Cool, thanks for testing.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20100513/39db4d7f/attachment.pgp>


More information about the lxc-devel mailing list