Oleg Nesterov <oleg@xxxxxxxxxx> writes:
> On 04/25, Chen Hanxiao wrote:
>>
>> We lacked of convenient method of getting the pid inside containers.
Are unix domain sockets not convinient?
>> If some issues occurred inside container guest, host user
>> could not know which process is in trouble just by guest pid:
>> the users of container guest only knew the pid inside containers.
>> This will bring obstacle for trouble shooting.
>>
>> This patch introduces pid_in_ns:
>> If one process is in init_pid_ns, /proc/PID/pid_in_ns
>> equals to /proc/PID;
>> if one process is in pidns, /proc/PID/pid_in_ns
>> will tell the pid inside containers;
>> if pidns is nested, it depends on which pidns are you in.
>
> Yes another /proc/pid/ file...
>
> Perhaps it would be better to change /proc/pid/status["Pid:"] to report the
> list of pid_nr's, from its namespace up to the observer's namespace. The same
> for "Tgid:".
>
> (Hmm. And why "Ngid:" was inserted between tid and tgid ?)
Add to that Ngid has a completely hosed implementation. It is a pid
stored in a pid_t, not a struct pid *. Sigh.
I am getting more and more tempted to obliterate task->pid. It just
encourages bad code.
>> +int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
>> + struct pid *pid, struct task_struct *task)
>> +{
>> + pid_t pid_in_ns;
>> + unsigned int level;
>> +
>> + level = pid->level;
>> + pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);
>
> This looks overcomplicated or I missed something?
I do think if we care we need to print the entire set of pids.
I don't know if /proc/pid/status is the proper place but ...
Eric
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
