[lxc-devel] RFC: Refactoring lxc-attach
Christian Seiler
christian at iwakd.de
Sun Apr 28 11:19:42 UTC 2013
Hi there,
any comments on my proposal?
> The basic idea for the refactored attach API would be:
>
> - pid_t lxc_attach(const char* name, const char* lxcpath,
> options...)
> + create a socket pair for sync
> + fork() (get rid of threading, nss stuff, etc.)
> |- same process:
> | + waits for signal from child
> | + [optional] puts grandchild in cgroup
> | + closes synchronisation sockets
> | + reap child process
> | + returns pid of grandchild
> |- child:
> + setns()
> + clone() with CLONE_PARENT
> | (child will be child of parent, this process
> | may exit and the parent won't care)
> |- same process
> | + signal parent pid of grandchild
> | + exit
> |- grandchild process
> + [optional] drop privileges
> + [optional] apparmor stuff
> + set environment
> + execute stuff
>
> - options paremeter:
> + pointer to some struct that contains all the options that
> may be specified to the current lxc-attach process
> + also contains function pointer to the function that is to
> be
> executed inside the container
> - lxc_attach_exec
> default implementation that executes a specific
> command
> - lxc_attach_shell
> default implementation that executes a shell
> - this would allow for example the following python code
> using the API (if one doesn't want to exec() a command
> or a shell):
> def test_file_exists():
> sys.exit(os.path.exists('/foo/bar') and 0 or 1)
> proc = container.attach(run=test_file_exists)
>
> lxc-attach's main would then trivially be:
>
> 1. parse parameters, fill the options struct
> 2. call lxc_attach()
> 3. waitpid() on attached process
> 4. pass through exit code
>
> Comments welcome, if you think this is the right way to go, then I'll
> go
> ahead and implement it in the next few days.
-- Christian
More information about the lxc-devel
mailing list