Quoting Rob Landley (r...@landley.net):
> On 09/23/2013 11:19:17 AM, Serge Hallyn wrote:
> >Quoting Rob Landley (r...@landley.net):
> >> On 09/12/2013 01:27:07 PM, Christian Seiler wrote:
> >> > Hi there,
> >> >
> >> > just a quick question: currently, rootfs is pinned with a
> >.hold file
> >> > in
> >> > the parent directory (which btw. does not help against file
> >systems
> >> > that
> >> > are already mounted on the host but directly in the rootfs
> >directory).
> >> > The problem with the .hold file is that it doesn't make the
> >directory
> >> > necessarily pretty; I tend to mount all rootfs to
> >/srv/lxc/$container
> >> > (config remaining in /var/lib/lxc), and then when doing a ls
> >> > /srv/lxc, I
> >> > see tons of .hold files. (I'm not even sure that they are removed
> >> > after
> >> > container termination - but even if they are, the default
> >state of a
> >> > typical system tends to be that at least some containers are
> >> > running...)
> >> >
> >> > Couldn't we just open $rootfs/lxc.hold for writing, keep the
> >fd (as
> >> > current pinfd) and then unlink (!) the file directly? According to
> >> > POSIX
> >> > semantics, the file is then still open and the pinning should work
> >> > (now
> >> > also for the above case), but there are no files lying around
> >anymore.
> >> > (Note: I didn't test that, it could well be that that doesn't
> >work.)
> >> >
> >> > Thoughts?
> >>
> >> Why doesn't keeping a file open to the directory itself work? (I'm
> >> assuming it doesn't, I'm wondering why.)
> >
> >Tried it under tmpfs, and open("/mnt", O_RDWR) with tmpfs mounted
> >at /mnt does not work, gives EISDIR. O_RDONLY does work, but that
> >doesn't prevent mount -o remount,ro.
>
> The filesystem hitting an error (including one from the block
> device) can make most filesystems remount themselves read only,
> forcibly even with active writers. The permissions to do so from
> userspace should be roughly analogous to calling shutdown or "kill
> -1"? (I'm wondering what lxc's interest is in preventing the
> container-local root from doing something container-local
> dangerous?)
Some people have a block device mounted at /var/lib/lxc, and
keep all their containers and rootfs' there.
If they start a single container and shut it down, most distros
during shutdown will mount -o remount,ro /, which will end up
remounting /var/lib/lxc ro. Now other containers can't start up.
So it's not actually container-local dangerous.
Now, it's possible that we should just make sure that any
directory-backed (or btrfs-backed) containers always bind-mount
$rootfs onto itself. That might work and might be a cleaner
solution.
-serge
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
