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 | m...@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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
