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

[Daniel Lezcano]

Andrian Nord wrote:
> 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)
>   
Yes, the forker command handler and the wait-all-child can be merged in 
a single mainloop, ala lxc-mainloop, so there is only one process 
instead of two.

>> 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?
>   
Yes and there are also some cleanups Dietmar and I we don't had time to do.
Dietmar did an excellent work on the 'forker', I played with it and it 
works very well.

Do you plan to update the 'forker' ? (sorry this is something I have in 
my TODO list but I don't have spare time for that).