[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-users/attachments/20100513/39db4d7f/attachment.pgp>
More information about the lxc-users
mailing list