make ps command to print the pid in container, not the pid in host

[keloyang]

make ps command to print the pid in container, not the pid in host
this pr depends upon #1013
before this ptch:

root@ubuntu:~/workspace/runc-test# ./runc ps test 
UID        PID  PPID  C STIME TTY          TIME CMD
root     18185 18176  0 20:43 pts/12   00:00:00 sh
root     18192 18185  0 20:43 pts/12   00:00:00 sleep 9000

after this patch:

root@ubuntu:~/workspace/runc-test# ./runc ps test    
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 20:20 pts/12   00:00:00 sh
root        14     1  0 20:22 pts/12   00:00:00 sleep 100000
root       130   125  0 20:35 pts/5    00:00:00 ps -ef

Signed-off-by: Shukui Yang [email protected]

[cyphar]

Ah, okay. This is how I would like this to be done, unfortunately there are several potential problems with trying to Setns in Go:

1. Since Go programs are multithreaded (with no way of disabling it), this syscall can fail arbitrarily (the interface says that you should only use setns for single-threaded programs).
2. In SELinux (and rootless container) contexts, you'll also need to join the user namespace as well.

I think this would work better if we made libcontainer.Container.Processes() do all of this internally, where it goes through the full runc exec process (but only joins the User and PID namespaces). Then we send the PIDs to the main runC process over an AF_UNIX socket.

[hqhq]

I still don't think we need to show inner pids for runc ps, the global pids would be more useful, and we can do runc exec <id> ps -ef if we really need to know the inner pids. Plus, docker top shows global pids all the time and it works well, no one complained about it, why we think runc users would like this?

Even if someone really like it, we should add option like runc ps --inner <id> instead of replacing the default.

[cyphar]

The "send PIDs over an AF_UNIX socket" means you'll get PIDs in your current PID namespace (as close to "global" as you can get). This was one of the extensions to the current set up I was considering (it means you could use libcontainer.Container.Processes() inside a rootless container -- since we don't have cgroups).

[cyphar]

I don't remember the usecase that @hqhq gave, but with this patch runc ps isn't much different to runc exec test ps, which makes it a bit useless IMO. I'm not really a huge fan of the current runc ps interface overall, so @hqhq can probably give you some more feedback than I can. :P

[hqhq]

@cyphar I don't have any usecases, I only mentioned we can give it a try following your comments in #808 😄 And after a bit more think, I don't think it it useful.

[keloyang]

@cyphar http://man7.org/linux/man-pages/man2/setns.2.html
A process may not be reassociated with a new mount namespace if it is multithreaded and A multithreaded process may not change user namespace with setns(),I'm not sure if setns(...pid) is ok, and I will try that libcontainer.Container.Processes() do all of this internally.
@hqhq I do think we can add --inner, How do others think ?

[crosbymichael]

I think the global pids are more useful for people making the call outside the container. Thanks for the PR @keloyang but I think we shouldn't do this for the other reasons @hqhq said.

Sorry if there was confusion about this feature in that issue.