Allow for main process to just be sleep() - aka: no cmd

[duglin]

This adds support for starting a container w/o a cmd - which will mean that
it creates the container and then holds on to it forever so the namespaces
and cgroups don't go away. Then the user can then do things like
runc exec ... to run whatever other cmds they need to run.
This allows for cases where the container needs to be setup in advance of
knowing what cmds will be run.

Instead of calling system.Execv to run the cmd we just select {}, which
sleeps forever.

This assumes that we don't need to have the apparmor stuff kick-in because
there's no risk of this process doing anything bad from this point on.
Is this a safe assumption? If not, we'll need another way to fork/exec+sleep.

Signed-off-by: Doug Davis dug@us.ibm.com

[duglin]

ping @julz

[wking]

On Sun, Jan 10, 2016 at 12:19:42PM -0800, Doug Davis wrote:

This adds support for starting a container w/o a cmd - which will
mean that it creates the container and then holds on to it forever
so the namespaces and cgroups don't go away. Then the user can then
do things like runc exec ... to run whatever other cmds they need
to run. This allows for cases where the container needs to be setup
in advance of knowing what cmds will be run.

I'd rather have the container process exit immediately (instead of
sleeping) where it would usually be executing the user-defined
container code. I went with the “sleep forever” approach in v0.1.0 of
ccon 1. However, for the ccon-ced (create/exec/delete) wrapper that
landed in v0.3.0 2, I changed the no-process (or process.args)
behavior to “exit immediately” [3,4]. That allows me to:

1. Launch ccon with a config based on [5](in ‘ccon-ced create’) to
   create and setup the namespaces.
   a. A pre-start hook injected by ‘ccon-ced create’ bind-mounts the
   non-PID namespaces to files under /tmp/{container-id}/.
   b. Without a defined process, the container-process exits
   immediately after the pre-start hooks complete, and ccon and its
   wrapping ‘ccon-ced create’ return shortly thereafter.
2. Launch ccon with a config based on [6](in ‘ccon-ced exec’) to
   execute a process in the namespaces from (1), with some additional
   config to create a new PID namespace and setup the appropriate
   /proc for that namespace. ‘ccon-ced exec’ injects the
   saved-from-(1) namespace paths whenever ‘path’ is set explicitly to
   ‘null’.

So using “exit immediately” makes (1) easy. Without it, there's not a
simple way to get just the runtime's setup functionality (maybe you'd
have a post-start hook that SIGKILLed the container process?). If you
use a different default behavior, it seems like you'd need a way to
select the “exit immediately” behavior when it was appropriate.

In ccon v0.2.0+, folks wanting that sort of functionality can use
process.host 7 to load a reaping binary from their host namespace.
And supporting something like process.host makes the whole thing
nicely flexible, because it's easy for folks to compile and plug in a
static binary with whatever functionality they find most appropriate.

See also the optional-reaper discussion in [8](reaping seems like
reasonable functionality for a “block forever” container process, if
that ends up getting built into runC).

 Subject: desktop sandboxes in the opencontainer initiative?
 Date: Tue, 20 Oct 2015 03:59:16 -0700 (PDT)
 Message-Id: <254f5101-5d1a-41dc-89f6-dbc9e7a59389@opencontainers.org>

[mrunalp]

I think that it is a better idea to leave this out. How different runtimes implement this could differ and lead to different behaviors. Using a simple rootfs with a binary that does this is more portable.

[crosbymichael]

Also with the create / start / destroy workflow we are investigating it will solve much of your usecase. We can revisit other options if not.

[duglin]

Yup. With the create/start split we can close this.

-Doug

Sent from my iPhone

On Jan 14, 2016, at 4:48 PM, Michael Crosby notifications@github.com wrote:

Also with the create / start / destroy workflow we are investigating it will solve much of your usecase. We can revisit other options if not.

—
Reply to this email directly or view it on GitHub.

[duglin]

I'm not so sure we can close this one. If the split between create/start still requires a main process then we may need the user to run some kind of "sleep" as the main process. But, if there is no "sleep" in the image then they're going to run into a problem. This PR allows them to do a "sleep" w/o requiring an exe in the image to do it.