On 05/03/2011 06:11 PM, Serge Hallyn wrote: > Quoting Daniel Lezcano ([email protected]): >> 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 ([email protected]): >>>>> 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<[email protected]> >> 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 ? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Lxc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxc-users
