[lxc-devel] startup scripts for lxc containers?

[Michael H. Warfield]

On Fri, 2010-01-15 at 22:49 -0500, Michael H. Warfield wrote: 
> On Sat, 2010-01-16 at 01:03 +0100, Michael Holzt wrote: 
> > > Oh, I thought init calls exit after it killed all children.
> 
> > No it does not.
> 
> > I was thinking about the problem the other day as well. I think some of it
> > is already covered by the work of Dietmar. I will describe my ideas in full
> > anyway:
> 
> > 1. lxc-start opens a pipe.
> 
> > 2. As the first process in the container a daemon e.g. lxc-ctld is launched
> >    which becomes pid 1. It will fork so that it will become pid 2 also and
> >    then in pid 1 a exec to the init binary is done so that init will be pid 
> >    1 as it expects. This process keeps one end of the pipe.
> 
> As I said in an earlier message, I like this idea.  Only downside is
> what if "lxc-ctld" is not present in the container?  My general attitude
> is that you should modify the container system as little as possible.
> 
> So...  That being said, let me posit this.  What if lxc_start were to be
> the daemon itself, both inside and outside of the container.  Basically,
> add another fork inside of lxc_clone() to do this dirty work.  It
> creates two copies of itself in the container namespace and then closes
> the socket pair and execs /sbin/init (or whatever) in the first one and
> holds the socket open as a phantom (a process from a binary outside the
> container) in the second process, maybe renaming the title to something
> to make it look pretty in process 2.  Back in the parent lxc_start, you
> wait on that socket to close when that grandchild process in the
> container gets killed.  Would this not work?  That would not involve
> adding a binary or modifying the startup process in the container and
> you don't have a separate binary to launch, since it's just yet another
> clone of the lxc_start binary that kicked the whole thing off.

I'm only just now beginning to really delve into the code for this but
it immediate jumps out at me that it appears we already have the tools
in lxc_start() to do this.  It's already creating a socket set and it's
already using that socket set to coordinate parent and child during
initialization of the container and then closing it.  Ok...  So we
create a child (pid 1 in the container) and a grandchild (pid 2 in the
container), after the initialization handshake between parent and child,
we close the sockets in the child and fire off init but leave them open
in the parent and grandchild and wait on them in the parent.  Wouldn't
this work?  Am I missing something?  I'm going to tinker with this a bit
in the next few days.  Part of getting a feel for the code base here and
all...  :-)

> > 3. Now how to detect shutdown or reboot, i had two ideas.
> > 
> >    One is to modify /etc/init.d/halt and /etc/init.d/reboot to send a
> >    signal to lxc-ctld. Two different signals, one for halt, one for 
> >    reboot.
> > 
> >    Other idea is to just have init-ctl sit there. When it receives sigterm
> >    - emitted by init upon shutdown/reboot - it will determine runlevel
> >    (0 or 6) and thus know if it is reboot or halt.
> > 
> >    lxc-ctld will signal this to lxc-start through the pipe so that
> >    lxc-start now knows what action to take.
> > 
> >    lxc-ctld will not exit on sigterm but wait to be killed through sigkill
> >    by init.
> > 
> > 4. lxc-start which knows that shutdown or reboot is in progress until
> >    lxc-ctld process is no longer in the process table and then kills
> >    the init in the container.
> > 
> > Problems: We know the "outer" pid of the init in the container but not
> > of lxc-ctld. Maybe change argv[0] to make it findable.
> > 
> > Comments?
> > 
> > 
> > 
> > Regards
> > Michael
> > 
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________ Lxc-devel mailing list Lxc-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel

-- 
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/20100115/6378d61b/attachment.pgp>