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

[Andrian Nord]

On Sat, Nov 07, 2009 at 12:39:47AM +0100, Daniel Lezcano wrote:
> 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.

Eh, that's what I've missed, that we could fork 'forker' before init.
Yes, not I got it, thanks for clarification.
 
> Yep, but I prefer to keep the usual process hierarchy :)
> I don't like the idea of having two child reapers in the container.
 
Or course, I've just didn't catch the above idea initially, so that was 
some wrong way of thinking =)

> Are these two ?
> 
> http://bugs.gentoo.org/attachment.cgi?id=209000
> http://bugs.gentoo.org/attachment.cgi?id=209001
 
Yes, there are. As you may see, it requires some additional work - some
style fixes for capabilities and more user-friendly implementation of
config.include. But this is different thread, I hope i'll post it soon,
just as I finish reconfiguring my home network for new server.

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

Anyway, what prevent us from using 'forker' in just same pattern for
application containers. That will just provide three processes in such
container instead of two. Even more, as you have 'forker' command line
switch, user may not use it for application container.

(Actually in this scheme forker may be merged with lxc-init, i.e. it may
act as init, depending on some switch, forking specified command just
after own creating and quitting when no childes left)

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

Heh, everything is useful, at least for someone, otherwise it wouldn't
be suggested, right? Question is in that if there is some better ways of
implementing what is suggested. That's question I couldn't answer in
that particular topic, because of insufficient knowledge =)

(In our current problem it could be useful in long perspective (it will
simplify userspace configuration), but maybe it will add some
additional mess into kernelspace, so I really don't know what is better)

> 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.

Same for me. That's why I've raised that question - I don't what to rely
on sysvinit-in-container in rc-scripts.

Sorry, it was my mistake of misuse of terminology. Of course, I has no
plans of implementing full-scale init program to replace container's
init system. I was suggesting such strange system, just because I've
failed to get the idea of preforking required daemon from above. So,
again, that was wrong way of my thoughts, nevermind it.

So, imo, only problem is old forker code, that should be updated for
the current master, right?