[lxc-devel] Change rootfs pinning mechnism

[Michael H. Warfield]

On Fri, 2013-09-13 at 12:18 -0400, Stéphane Graber wrote: 
> On Fri, Sep 13, 2013 at 05:11:37PM +0100, Christian Seiler wrote:
> > Hi there,
> > 
> > > Concur on the revert.
> > >
> > > What is really gained by deleting that file?  I agree with the basic
> > > idea of moving and renaming that file to hold the mount open but, are 
> > > we
> > > really that worried that someone will inadvertently delete that file?
> > > It shouldn't be a security issue and I don't think I see someone
> > > deleting it to be stupid (but then you're still holding it open and 
> > > the
> > > general case applies).  I'm just not sure what was being accomplished 
> > > by
> > > the whole delete while held action here.
> > 
> > I see a consensus forming:
> > 
> >   - change name to something starting with a dort _inside_ the rootfs
> >     (e.g. .lxc-running)
> >   - don't delete it immediately
> >   - remove it at stop
> > 
> > Agreed?

> Whatever we end up with, please make sure we don't fail if the file
> can't be created (read-only rootfs).

> I'm not completely sure what a .lxc-running file would gain us since we
> already have a unique abstract socket path which is much more reliable
> to check if a given container is already running.

> It's also not impossible that someone may actually want to run the same
> container multiple times, so using the pin to prevent double-start seems
> odd and would completely prevent shared rootfs.

That's an interesting point.  A couple of interesting points that I'm
not sure are not mutually exclusive.

The later point, running a shared rootfs, could be handled by a private
temp directory and files associated with unique host pids.  That's kind
of a standard practice and could be in /run or /tmp or some other well
defined location.  Just having a process camped out on it (CWD) could
hold the mount point.

Now, the former point, the "unique abstract socket path" raises yet
another interesting point.  Is that unique within the context of a
shared rootfs between multiple containers?  I'm not familiar with it to
comment but an exist file being held open for an orthogonal purpose
makes sense to me as well, as long as it's dual purpose is well
documented.

> I personally think that we shouldn't use the pin as an indication of the
> container running at all, but only for its original purpose which is to
> have a writable file open on the filesystem in order to prevent a
> read-only remount of that fs.

Concur.

However...  What if there is more than one file system?  I've seen (in
the distant past) where the old "remount -ro" problem bit us in the ass
on file systems other than the root fs.  Are we sure this pin is enough?
Maybe that's all been fixed and no longer a worry.  I haven't retested
that remount bullshit in a couple of years.

> > The only thing I'm not really sure about:
> > 
> >   - fail if it already exists
> >          => let's say one has an LXC running somewhere, the power goes 
> > out,
> >             no UPS, the host reboots after some time, tries to 
> > auto-start the
> >             LXC on boot but LXC won't start because .lxc-running 
> > exists...
> >   - perhaps we could write the pid of the lxc-start process in there, so 
> > that
> >     it may check whether the container is really running?
> > 
> > -- Christian

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/20130913/52799c38/attachment.pgp>