[Libct] Queries regarding libctd( libct daemon) code

[Andrey Wagin]

Hi Monali,

2014-12-06 0:55 GMT+03:00 Monali Porob <Monali.Porob at huawei.com>:
> Hi Andrey ,
>
> Thank you so much for the reply .
>
>
>
> My understanding is as below
>
> The libct_container_open_by_pid () would work  with the assumption that for
> the below use case process/executable P1 communicates pgm1 PID to P2. P2 can
> then get container handle using this API and call
> libct_container_enter_execv() to start pgm2. I guess with this it would
> solves the  use-case.

Yes, it would. If we want to execute a process in a container, we need
to know a pid of another process from this CT. Then we can read cgroup
configuration from  /proc/PID/cgroup, and /proc/[pid]/ns/ contains
files which are referring to namespace entries.

>
> Qn :
>
> Any tentative plans when this API will be available to try out ?

I can try to implement it on this week. If you want, you could try to
implement this functionality. It should not be complicated.

>
>
> Qn:
>
> I was not clear  with the restrictions though . Would these restrictions be
> listed somewhere in gits logs etc. My bad for not really understanding it .
> If you could elaborate , it would be great.  Did you mean getting the return
> status of pgm1 which could be have PID = 1 in case of a container with PID
> namespaces.

Actually it's true for cases without PID namespaces too. waitpid() is
able to wait only children of the current process, so P2 isn't able to
wait pgm1.
I can rephrase my point. If you want to have a full control of
containers, you need to have a daemon. If you want to execute
processes in containers, libct_container_open_by_pid () should be
enough for you.

>
>
>
> I also wrote a simple daemon process (D) holding the container handle  and
> was able to run a pgm 1 using  libct_container_spawn_execv()  and then after
> some later point signal process D to run pgm2 using
> libct_container_enter_execv() in libct. That worked .
>
> The only thing is that currently libct_container_wait() can only monitor
> pgm1. In libct,  Is there plan  to support monitoring multiple processes
> running in the container.

I have add a type of a handle that represents processes. It allows to
wait processes and gets their exit status.
https://github.com/xemul/libct/pull/28

>
> Qn : Do provide any feedback you have .
>
>
>
> Also while  writing to your  I realized that you forgot to copy your
> previous reply to the mailing list . Let me know if you want me to send this
> reply back on the list.

Sorry, it's my fault. I've added it back.

Thanks,
Andrey

>
>
>
> Thanks and Regards,
>
> Monali
>
>
>
>
>
> From: Andrey Wagin [mailto:avagin at gmail.com]
> Sent: Wednesday, December 03, 2014 12:15 PM
> To: Monali Porob
> Subject: Re: [Libct] Queries regarding libctd( libct daemon) code
>
>
>
>
> On Dec 2, 2014 11:01 PM, "Monali Porob" <Monali.Porob at huawei.com> wrote:
>>
>> Hi all ,
>>
>> I was doing some research with how libct library could be used in the
>> existing project .
>>
>>
>>
>> I am looking to check the support for following  use case  where I can
>> have a persistent process to manage the containers and  one has the ability
>> to have multiple processes running in the container.
>>
>>
>>
>> Basically the ability to do the following using libct.
>>
>> Executable 1 ( P1)
>>
>> a)      Create container say C1
>>
>> b)      Spawn long running pgm in C1
>>
>>
>>
>> Executable 2 (P2)
>>
>> a)      Enter existing container C1
>>
>> b)      Run program pgm2 in C1
>>
>>
>>
>>
>>
>> Qn 1:  Is there a plan to support the above use case with libct.
>
> I have a plan to add libct_container_open_by_pid (). This function will
> return a container object which is associated with the process with a
> specified pid. Probably such objects will have some restrictions. For
> example, it's not obvious how to get exit code of the init process.
>
> In your case, this process will be pgm. Will it be usefull for you?
>
>>
>>
>>
>> When exploring  libct  , I came across libctd daemon and proxy
>> backend/unix backend .
>>
>> Qn2:  Was curious to know why the libct daemon code , unix backend is
>> removed in the git master branch.
>
> I think here was a few reasons.
>
> The libct library isn't appropriate place for this functionality. This
> daemon is not as simple as it looks like. I think if we really need these
> daemon, we shoult create a separate project.
>
> When we started developing libct, we didn't see users for this daemon. If we
> look at Docker, LXC, OpenVZ, they have own daemons which do this work and
> some other. Nobody wants to have one more daemon to handle containers.
>
> Thanks,
>
> Andrey
>
>>
>>
>>
>>
>>
>> Regards,
>>
>> Monali.
>>
>>
>> _______________________________________________
>> Libct mailing list
>> Libct at openvz.org
>> https://lists.openvz.org/mailman/listinfo/libct