Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote: > Ferenc Wagner writes: > >> Daniel Lezcano writes: >> >>> Ferenc Wagner wrote: >>> Daniel Lezcano writes: > Ferenc Wagner wrote: > >> While playing with lxc-start, I noticed that /tmp is infested by >> empty lxc-r* directories: [...] Ok, this name comes from lxc-rootfs >> in conf.c:setup_rootfs. After setup_rootfs_pivot_root returns, the >> original /tmp is not available anymore, so rmdir(tmpname) at the >> bottom of setup_rootfs can't achieve much. Why is this temporary >> name needed anyway? Is pivoting impossible without it? > That was put in place with chroot, before pivot_root, so the distro's > scripts can remount their '/' without failing. > > Now we have pivot_root, I suppose we can change that to something > cleaner... Like simply nuking it? Shall I send a patch? >>> Sure, if we can kill it, I will be glad to take your patch :) >> I can't see any reason why lxc-start couldn't do without that temporary >> recursive bind mount of the original root. If neither do you, I'll >> patch it out and see if it still flies. > > For my purposes the patch below works fine. I only run applications, > though, not full systems, so wider testing is definitely needed. > > Thanks, > Feri. > > From 98b24c13f809f18ab8969fb4d84defe6f812b25c Mon Sep 17 00:00:00 2001 > From: Ferenc Wagner > Date: Thu, 6 May 2010 14:47:39 +0200 > Subject: [PATCH] no need to use a temporary directory for pivoting > > That was put in place before lxc-start started using pivot_root, so > the distro scripts can remount / without problems. > > Signed-off-by: Ferenc Wagner > --- > src/lxc/conf.c | 28 +++- > 1 files changed, 3 insertions(+), 25 deletions(-) > > diff --git a/src/lxc/conf.c b/src/lxc/conf.c > index b27a11d..4379a32 100644 > --- a/src/lxc/conf.c > +++ b/src/lxc/conf.c > @@ -588,37 +588,15 @@ static int setup_rootfs_pivot_root(const char *rootfs, > const char *pivotdir) > > static int setup_rootfs(const char *rootfs, const char *pivotdir) > { > - char *tmpname; > - int ret = -1; > - > if (!rootfs) > return 0; > > - tmpname = tempnam("/tmp", "lxc-rootfs"); > - if (!tmpname) { > - SYSERROR("failed to generate temporary name"); > - return -1; > - } > - > - if (mkdir(tmpname, 0700)) { > - SYSERROR("failed to create temporary directory '%s'", tmpname); > - return -1; > - } > - > - if (mount(rootfs, tmpname, "none", MS_BIND|MS_REC, NULL)) { > - SYSERROR("failed to mount '%s'->'%s'", rootfs, tmpname); > - goto out; > - } > - > - if (setup_rootfs_pivot_root(tmpname, pivotdir)) { > + if (setup_rootfs_pivot_root(rootfs, pivotdir)) { > ERROR("failed to pivot_root to '%s'", rootfs); > - goto out; > + return -1; > } > > - ret = 0; > -out: > - rmdir(tmpname); > - return ret; > + return 0; > } > > static int setup_pts(int pts) Thanks, I will test it with another patch I have in my backlog fixing the pivot_root. I Cc'ed the lxc-devel mailing list which is more adequate for this kind of discussion. Thanks again. -- Daniel -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Daniel Lezcano writes: > Ferenc Wagner wrote: > >> Ferenc Wagner writes: >> >>> Daniel Lezcano writes: >>> Ferenc Wagner wrote: > Daniel Lezcano writes: > >> Ferenc Wagner wrote: >> >>> While playing with lxc-start, I noticed that /tmp is infested by >>> empty lxc-r* directories: [...] Ok, this name comes from lxc-rootfs >>> in conf.c:setup_rootfs. After setup_rootfs_pivot_root returns, the >>> original /tmp is not available anymore, so rmdir(tmpname) at the >>> bottom of setup_rootfs can't achieve much. Why is this temporary >>> name needed anyway? Is pivoting impossible without it? >> >> That was put in place with chroot, before pivot_root, so the distro's >> scripts can remount their '/' without failing. >> >> Now we have pivot_root, I suppose we can change that to something >> cleaner... > > Like simply nuking it? Shall I send a patch? Sure, if we can kill it, I will be glad to take your patch :) >>> >>> I can't see any reason why lxc-start couldn't do without that temporary >>> recursive bind mount of the original root. If neither do you, I'll >>> patch it out and see if it still flies. >> >> For my purposes the patch below works fine. I only run applications, >> though, not full systems, so wider testing is definitely needed. >> >> From 98b24c13f809f18ab8969fb4d84defe6f812b25c Mon Sep 17 00:00:00 2001 >> From: Ferenc Wagner >> Date: Thu, 6 May 2010 14:47:39 +0200 >> Subject: [PATCH] no need to use a temporary directory for pivoting >> [...] > > We can't simply remove it because of the pivot_root which returns EBUSY. > I suppose it's coming from: "new_root and put_old must not be on the > same file system as the current root." Hmm, this could indeed be a problem if lxc.rootfs is on the current root file system. I didn't consider pivoting to the same FS, but looks like this is the very reason for the current complexity in the architecture. Btw. is this really a safe thing to do, to pivot into a subdirectory of a file system? Is there really no way out of that? > But as we will pivot_root right after, we won't reuse the real rootfs, > so we can safely use the host /tmp. That will cause problems if rootfs is under /tmp, don't you think? 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. So why not require that rootfs is a separate filesystem, and let the user deal with it by doing the necessary bind mount in the lxc config? > --- lxc.orig/src/lxc/conf.c > +++ lxc/src/lxc/conf.c > @@ -581,37 +581,24 @@ static int setup_rootfs_pivot_root(const > > static int setup_rootfs(const char *rootfs, const char *pivotdir) > { > - char *tmpname; > - int ret = -1; > + const char *tmpfs = "/tmp"; > > if (!rootfs) > return 0; > > - tmpname = tempnam("/tmp", "lxc-rootfs"); > - if (!tmpname) { > - SYSERROR("failed to generate temporary name"); > + if (mount(rootfs, tmpfs, "none", MS_BIND|MS_REC, NULL)) { > + SYSERROR("failed to mount '%s'->'%s'", rootfs, "/tmp"); You probably meant tmpfs instead of "/tmp" in SYSERROR() above. -- Thanks, Feri. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote: > Daniel Lezcano writes: > > >> Ferenc Wagner wrote: >> >> >>> Ferenc Wagner writes: >>> >>> Daniel Lezcano writes: > Ferenc Wagner wrote: > > >> Daniel Lezcano writes: >> >> >>> Ferenc Wagner wrote: >>> >>> While playing with lxc-start, I noticed that /tmp is infested by empty lxc-r* directories: [...] Ok, this name comes from lxc-rootfs in conf.c:setup_rootfs. After setup_rootfs_pivot_root returns, the original /tmp is not available anymore, so rmdir(tmpname) at the bottom of setup_rootfs can't achieve much. Why is this temporary name needed anyway? Is pivoting impossible without it? >>> >>> That was put in place with chroot, before pivot_root, so the distro's >>> scripts can remount their '/' without failing. >>> >>> Now we have pivot_root, I suppose we can change that to something >>> cleaner... >>> >> >> Like simply nuking it? Shall I send a patch? >> > > Sure, if we can kill it, I will be glad to take your patch :) > I can't see any reason why lxc-start couldn't do without that temporary recursive bind mount of the original root. If neither do you, I'll patch it out and see if it still flies. >>> For my purposes the patch below works fine. I only run applications, >>> though, not full systems, so wider testing is definitely needed. >>> >>> >From 98b24c13f809f18ab8969fb4d84defe6f812b25c Mon Sep 17 00:00:00 2001 >>> From: Ferenc Wagner >>> Date: Thu, 6 May 2010 14:47:39 +0200 >>> Subject: [PATCH] no need to use a temporary directory for pivoting >>> [...] >>> >> We can't simply remove it because of the pivot_root which returns EBUSY. >> I suppose it's coming from: "new_root and put_old must not be on the >> same file system as the current root." >> > > Hmm, this could indeed be a problem if lxc.rootfs is on the current root > file system. I didn't consider pivoting to the same FS, but looks like > this is the very reason for the current complexity in the architecture. > > Btw. is this really a safe thing to do, to pivot into a subdirectory of > a file system? Is there really no way out of that? > It seems pivot_root on the same fs works if an intermediate mount point is inserted between old_root and new_root but at the cost of having a lazy unmount when we unmount the old rootfs filesystems . I didn't find a better solution in order to allow the rootfs to be a directory with a full files system tree. I am looking at making possible to specify a rootfs which is a file system image or a block device. I am not sure this should be done by lxc but looking forward ... >> But as we will pivot_root right after, we won't reuse the real rootfs, >> so we can safely use the host /tmp. >> > > That will cause problems if rootfs is under /tmp, don't you think? > Right :) > 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 ? > So why not require that rootfs is a separate > filesystem, and let the user deal with it by doing the necessary bind > mount in the lxc config? > Hmm, that will break the actual user configurations. We can add a WARNING if rootfs is not a separate file system and provide the ability to let the user to do whatever he wants, IMO if it is well documented it is not a problem. >> --- lxc.orig/src/lxc/conf.c >> +++ lxc/src/lxc/conf.c >> @@ -581,37 +581,24 @@ static int setup_rootfs_pivot_root(const >> >> static int setup_rootfs(const char *rootfs, const char *pivotdir) >> { >> -char *tmpname; >> -int ret = -1; >> +const char *tmpfs = "/tmp"; >> >> if (!rootfs) >> return 0; >> >> -tmpname = tempnam("/tmp", "lxc-rootfs"); >> -if (!tmpname) { >> -SYSERROR("failed to generate temporary name"); >> +if (mount(rootfs, tmpfs, "none", MS_BIND|MS_REC, NULL)) { >> +SYSERROR("failed to mount '%s'->'%s'", rootfs, "/tmp"); >> > > You probably meant tmpfs instead of "/tmp" in SYSERROR() above. > yep. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Daniel Lezcano writes: > Ferenc Wagner wrote: > >> Daniel Lezcano writes: >> >>> We can't simply remove it because of the pivot_root which returns >>> EBUSY. I suppose it's coming from: "new_root and put_old must not >>> be on the same file system as the current root." >> >> Hmm, this could indeed be a problem if lxc.rootfs is on the current root >> file system. I didn't consider pivoting to the same FS, but looks like >> this is the very reason for the current complexity in the architecture. >> >> Btw. is this really a safe thing to do, to pivot into a subdirectory of >> a file system? Is there really no way out of that? > > It seems pivot_root on the same fs works if an intermediate mount > point is inserted between old_root and new_root but at the cost of > having a lazy unmount when we unmount the old rootfs filesystems. After pivoting? Could you please illustrate this? > I am looking at making possible to specify a rootfs which is a file > system image or a block device. I am not sure this should be done by > lxc but looking forward ... A device could be easily mounted by the user or by an lxc.mount.entry, so I don't think it needs special consideration. >>> But as we will pivot_root right after, we won't reuse the real >>> rootfs, so we can safely use the host /tmp. >> >> That will cause problems if rootfs is under /tmp, don't you think? > > Right :) Btw. my use case is exactly that: I mostly want to prune the namespace of the container, so I bind mount / to /tmp/.../jail and a couple of things (but not everything!) below that, and set rootfs=/tmp/.../jail. >> 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. >> So why not require that rootfs is a separate filesystem, and let the >> user deal with it by doing the necessary bind mount in the lxc >> config? > > Hmm, that will break the actual user configurations. Yes, sadly. > We can add a WARNING if rootfs is not a separate file system and > provide the ability to let the user to do whatever he wants, IMO if it > is well documented it is not a problem. Sure. It adds some complexity to the code, but lxc is there to help doing common tasks. 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? -- Thanks, Feri. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote: > Daniel Lezcano writes: > > >> Ferenc Wagner wrote: >> >> >>> Daniel Lezcano writes: >>> >>> We can't simply remove it because of the pivot_root which returns EBUSY. I suppose it's coming from: "new_root and put_old must not be on the same file system as the current root." >>> Hmm, this could indeed be a problem if lxc.rootfs is on the current root >>> file system. I didn't consider pivoting to the same FS, but looks like >>> this is the very reason for the current complexity in the architecture. >>> >>> Btw. is this really a safe thing to do, to pivot into a subdirectory of >>> a file system? Is there really no way out of that? >>> >> It seems pivot_root on the same fs works if an intermediate mount >> point is inserted between old_root and new_root but at the cost of >> having a lazy unmount when we unmount the old rootfs filesystems. >> > > After pivoting? Could you please illustrate this? > After the pivot_root syscall, we have oldroot and newroot. oldroot is underneath newroot, so after pivot_root, we can still access /oldroot. We want to umount the oldroot dir of course, but before umounting it, we have to umount all the subdirectories. When everything is unmounted, we finish to umount /oldroot. But in some circumstances, this umount fails with EBUSY, so we "detach" the directory with the MNT_DETACH option. http://sourceforge.net/mailarchive/message.php?msg_name=4B5B6DA5.6050302%40free.fr >> I am looking at making possible to specify a rootfs which is a file >> system image or a block device. I am not sure this should be done by >> lxc but looking forward ... >> > > A device could be easily mounted by the user or by an lxc.mount.entry, > so I don't think it needs special consideration. > There is the file system automatic detection of the image if the image is specified in the mount entry. I already coded that, but we can postpone that for the moment and focus on the pivot_root. But as we will pivot_root right after, we won't reuse the real rootfs, so we can safely use the host /tmp. >>> That will cause problems if rootfs is under /tmp, don't you think? >>> >> Right :) >> > > Btw. my use case is exactly that: I mostly want to prune the namespace > of the container, so I bind mount / to /tmp/.../jail and a couple of > things (but not everything!) below that, and set rootfs=/tmp/.../jail. > Ok, will fix that. >>> 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 ? >>> So why not require that rootfs is a separate filesystem, and let the >>> user deal with it by doing the necessary bind mount in the lxc >>> config? >>> >> >> Hmm, that will break the actual user configurations. >> > > Yes, sadly. > > >> We can add a WARNING if rootfs is not a separate file system and >> provide the ability to let the user to do whatever he wants, IMO if it >> is well documented it is not a problem. >> > > Sure. It adds some complexity to the code, but lxc is there to help > doing common tasks. 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. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Daniel Lezcano writes: > Ferenc Wagner wrote: > >> Daniel Lezcano 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. >> 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. -- Thanks, Feri. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote: > Daniel Lezcano writes: > > >> Ferenc Wagner wrote: >> >> >>> Daniel Lezcano 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. >>> 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. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Daniel Lezcano writes: > Ferenc Wagner wrote: > >> Daniel Lezcano writes: >> >>> Ferenc Wagner wrote: >>> Daniel Lezcano 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. I'm not sure what libdir is, doesn't this conflict with lxc-init? That's in the /usr/lib/lxc directory, at least in Debian. I'd vote for /usr/lib/lxc/oldroot in this setting. -- Regards, Feri. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
"Michael H. Warfield" writes: > On Wed, 2010-05-12 at 23:18 +0200, Daniel Lezcano wrote: > >> Ferenc Wagner wrote: >> >>> Daniel Lezcano writes: >>> Ferenc Wagner wrote: > Daniel Lezcano 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. Read-only /usr is a good thing, and stays perfectly possible with this choice. We're talking about an absolutely static directory, which serves as a temporary mount point only. > 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? There's nothing variable in this directory, and we need a single one only, and only when rootfs is the same file system as the current root (looking forward a little bit). I don't know the FHS by heart, maybe it has something to say about this. I'd certainly be fine with /var/lib/lxc/oldroot or something like that as well. -- Regards, Feri. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote: > Daniel Lezcano writes: > > >> Ferenc Wagner wrote: >> >> >>> Daniel Lezcano writes: >>> >>> Ferenc Wagner wrote: > Daniel Lezcano 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. >> > > I'm not sure what libdir is, doesn't this conflict with lxc-init? > That's in the /usr/lib/lxc directory, at least in Debian. I'd vote for > /usr/lib/lxc/oldroot in this setting. > $(libdir) is the variable defined by configure --libdir= Usually it is /usr/lib on 32bits or /usr/lib64 on 64bits. lxc-init is located in $(libexecdir), that is /usr/libexec or /libexec depending of the configure setting. -- ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel