Quoting Daniel Lezcano (daniel.lezc...@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 (frams...@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<gk...@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. > Otherwise: > Acked-by: Daniel Lezcano <daniel.lezc...@free.fr> ------------------------------------------------------------------------------ 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 Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users