no able to perform docker top

[GabyCT]

1. docker run -d --name test busybox sh -c "sleep 10"
2. docker top test -x PID TTY STAT TIME COMMAND 181 ? S< 0:00 [bioset]

Here it is the configuration that I am using cc-runtime : 3.0.10 commit : 3d402d1 Docker version 17.09.0-ce

[grahamwhaley]

Just for reference, the lack of docker ps is/was noted over in the limitations page: https://github.com/clearcontainers/runtime/blob/master/docs/limitations.md#pscommand

If we have added/fixed the runtime ps command, can we update the limitations doc as well :-)

[erick0z]

So, summarizing what's going on here:

• User executes docker top
• Docker daemon calls ListPids() through a containerd API client (libcontainerd.Client).
• Containerd API has ListPidsRequest and ListPidsResponse protobuf messages, and in the backend it spawns the runtime to actually call runtime ps –f json to get the PIDs array.
• Then Docker damon calls an exec(ps -ef) in the host and then it sorts the output matching with the previous PID list and returns a procList (ContainerTopOKBody).
• Finally, docker client prints the data in a fancy table.

@sameo @jodh-intel @sboeuf @devimc WDYT I was thinking on the following changes but I'm not sure if this will be accepted though:

Rely on runtime runtime ps -f table, instead of calling ps -ef on the host (runc and cc-runtime already provides the namespace process data).

• Let containerd API provide the runtime ps -f table data through a separate method
• Let dockerd use the containerd data to construct the ContainerTopOKBody

[jodh-intel]

Hi @erick0z - Thanks for the analysis.

Then Docker damon calls an exec(ps -ef) in the host and then it sorts the output matching with the previous PID list and returns a procList (ContainerTopOKBody).

That sounds horribly racy (and very hypervisor-runtime-unfriendly) to me. I agree that we really need a way to pass full ps details from the guest back to docker without the host-side PID lookup as that will be incorrect for a hypervisor-based runtime.

The problem is we have rather more PIDs to worry about than something like runc ;)

I almost wonder if we need to support multiple options for ps. Something like:

# Lists PIDs of cc-shim processes
# (Host-context process summary).
ps [--host]

# Lists PIDs of `cc-shim`, `cc-proxy` and hypervisor processes
# All host-context processes.
ps [--host] --all

# Lists PIDs of actual workload processes from the perspective of the agent
# (Guest root context processes).
ps --guest

# Lists PIDs of actual workload processes
# (Guest container context processes).
ps --guest --resolved

/cc @sboeuf, @devimc, @grahamwhaley.

[devimc]

thanks @erick0z for the analysis, and yes, definitely a patch in containerd and docker is needed