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
