[Lxc-users] mapping host PID <-> container PID

[Daniel Lezcano]

On 05/03/2011 06:11 PM, Serge Hallyn wrote:
> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>> On 05/03/2011 05:36 PM, Greg Kurz wrote:
>>> On Thu, 2011-04-28 at 09:41 -0500, Serge Hallyn wrote:
>>>> Quoting Ulli Horlacher (framstag at rus.uni-stuttgart.de):
>>>>> Is there a way to get the corresponding host PID for a container PID?
>>>>>
>>>>> For example: inside the the container the process "init" has always PID 1.
>>>>> But what PID has this process in the host process table?
>>>>>
>>>>> ps aux | grep ... is not what I am looking for, I want more robust solution.
>>>> There is nothing that gives you a 100% guaranteed correct race-free
>>>> correspondence right now.  You can look under /proc/<pid>/root/proc/ to
>>>> see the pids valid in the container, and you can relate output of
>>>> lxc-ps --forest to ps --forest output.  But nothing under /proc that I
>>>> know of tells you "this task is the same as that task".  You can't
>>>> even look at /proc/<pid>   inode numbers since they are different
>>>> filesystems for each proc mount.
>>>>
>>>> It's tempting to say that we should put a per-task unique id under
>>>> /proc/<pid>   for each task.  However that would likely be nacked because
>>>> it introduces a new namespace of its own.
>>>>
>>> An alternative could be to expose the container pid
>>> in /proc/<pid>/status. Could such a patch make it to mainline ?
>>>
>>> --- a/fs/proc/array.c
>>> +++ b/fs/proc/array.c
>>> @@ -337,6 +337,12 @@ static void task_cpus_allowed(struct seq_file *m,
>>> struct task_struct *task)
>>>   	seq_putc(m, '\n');
>>>   }
>>>
>>> +static void task_vpid(struct seq_file *m, struct task_struct *task)
>>> +{
>>> +	struct pid_namespace *ns = task_active_pid_ns(task);
>>> +	seq_printf(m, "Vpid:\t%d\n", ns ? task_pid_nr_ns(task, ns) : 0);
>>> +}
>>> +
>>>   int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
>>>   			struct pid *pid, struct task_struct *task)
>>>   {
>>> @@ -354,6 +360,7 @@ int proc_pid_status(struct seq_file *m, struct
>>> pid_namespace *ns,
>>>   	task_cpus_allowed(m, task);
>>>   	cpuset_task_status_allowed(m, task);
>>>   	task_context_switch_counts(m, task);
>>> +	task_vpid(m, task);
>>>   	return 0;
>>>   }
>>>
>>> Signed-off-by: Greg Kurz<gkurz at fr.ibm.com>
>> I think we should propose this patch for mainline inclusion. The
>> vpid does not give, by its own, enough information for the pid
>> namespace. How can we rebuild a pid ns tree ? I guess we can look
>> for the vpid 1 as the root node of the process tree no ?
> You mean find pid 1 for the task's container, and print out it's
> pid in current's pid_ns, i.e.
>
> Container_init:<pid>
>
> That'd be very useful, and, again, does not AFAICS risk introducing
> a new namespace.

Yes. And I think the positive side effect is we can determine if the pid 
belongs to the same pid namespace than the current one when the 
container_init is 1, no ?