[lxc-devel] Any way of inserting some process into specified namespace

[Daniel Lezcano]

Andrian Nord wrote:
> On Fri, Nov 06, 2009 at 02:52:58PM +0100, Daniel Lezcano wrote:
>> No, there is no way to insert a process in a new namespace without an 
>> daemon running inside the container.
>> There is a prototype with a daemon, done by Dietmar, working very well, 
>> in the git branch 'forker';
>> it is not up-to-date with the master.
>>
>> http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=shortlog;h=refs/heads/forker
> 
> Am I correct, that this daemon acting as custom init, keeping
> communication channel with lxc-start, forking, instead of exec'ing, real
> init, and it could be used for forking arbitry commands inside container
> namespace? 

The first process in the container (aka pid 1) is still in the lxc code 
until it execs the /sbin/init.

When the option of the forker is set, the lxc code fork/exec the 
'forker', so it has the pid 2, and then it execs /sbin/init (pid 1).

The 'forker' and the lxc-exec/lxc-cmd communicate via a fifo.

Dietmar and I, we think about this approach for the future 
checkpoint/restart.

> If yes, I've was thinking about something like that reading thread about
> cloneat/sys_clone3 and I like that idea very much, because it may have many
> benefits over just ability of running commands inside containers.
> And, most probably, there is no big problem in fact, that actual init will
> run with pid different from 1.

Yep, but I prefer to keep the usual process hierarchy :)
I don't like the idea of having two child reapers in the container.

> I'll try to reimplement this with master branch some time later 
> (before that,
> I should post here two already existing patches, that require some
> additional rework before posting =))

Are these two ?

http://bugs.gentoo.org/attachment.cgi?id=209000
http://bugs.gentoo.org/attachment.cgi?id=209001

> Anyway, thanks for idea, it looks like just something implementing of
> which i'm capabable in.
> 
>> But unfortunately it is not compatible with the application containers.
>> May be there is a solution but I had no time to investigate.
> 
> Why? As far as I could see, you are using lxc-init as primary process
> for application containers, so, why it couldn't replaced by custom init
> from above, forking exact application instead of /sbin/init?

Hmm, yes, you are right. The design differs from application container 
and system container.

>> There was a discussion around a cloneat syscall, making possible to fork 
>> a process and re-parent it to the specified process.
>>
>> https://lists.linux-foundation.org/pipermail/containers/2009-October/021476.html
>>
>> Maybe you can react to this email ?
> 
> "React"? I'm not absolutelly sure, what do you mean with that =)

Oh, just say that may be useful :)
Anyway, this is not important.

> I'm not familiar with kernel programming, so I can't say anything
> usefull about this idea. But from my point, in task of execing programs
> inside of container, custom init is something much more simple, still,
> of course, it hardly could be used for checkpointing/restarting.

I really want to keep the distro init as the pid 1 because we don't know 
how can behave the system regarding the different 'init' sysv / upstart 
and I don't want to rewrite a custom init taking into account the 
different implementations. For the application containers that makes 
sense to embed the 'forker' in the lxc-init. I am sure we can keep the 
init pid for system container running with a 'forker' as pid 2 and embed 
the 'forker' in lxc-init. The challenge is to write a clean and common 
code for the application and system container.