How can I see the full command of a running container/process in Docker?
$ docker ps --all
CONTAINER ID IMAGE COMMAND CREATED
Use:
docker inspect -f "{{.Path}} {{.Args}} ({{.Id}})" $(docker ps -a -q)
That will display the command path and arguments, similar to docker ps
.
Use runlike from git repository https://github.com/lavie/runlike
To install runlike
pip install runlike
As it accept container id as an argument so to extract container id use following command
docker ps -a -q
You are good to use runlike to extract complete docker run command with following command
runlike <docker container ID>
docker ps --no-trunc
will display the full command along with the other details of the running containers.
Use:
docker inspect -f "{{.Name}} {{.Config.Cmd}}" $(docker ps -a -q)
... it does a "docker inspect" for all containers.
Moving Dylan's comment into a full-blown answer because TOO USEFUL:
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock assaflavie/runlike YOUR-CONTAINER
What does it do? Runs https://github.com/lavie/runlike inside a container, gets you the complete docker run command, then removes the container for you.
TL-DR
docker ps --no-trunc
and docker inspect CONTAINER
provide the entrypoint executed to start the container, along the command passed to, but that may miss some parts such as ${ANY_VAR}
because container environment variables are not printed as resolved.
To overcome that, docker inspect CONTAINER
has an advantage because it also allow to retrieve separately env variables and their values defined in the container from the Config.Env
property.
docker ps
and docker inspect
provide information about the executed entrypoint and its command. Often, that is a wrapper entrypoint script (.sh
) and not the "real" program started by the container. To get information on that, requesting process information with ps
or /proc/1/cmdline
help.
1) docker ps --no-trunc
It prints the entrypoint and the command executed for all running containers.
While it prints the command passed to the entrypoint (if we pass that), it doesn't show value of docker env variables (such as $FOO
or ${FOO}
).
If our containers use env variables, it may be not enough.
For example, run an alpine container :
docker run --name alpine-example -e MY_VAR=/var alpine:latest sh -c 'ls $MY_VAR'
When use docker -ps such as :
docker ps -a --filter name=alpine-example --no-trunc
It prints :
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5b064a6de6d8417... alpine:latest "sh -c 'ls $MY_VAR'" 2 minutes ago Exited (0) 2 minutes ago alpine-example
We see the command passed to the entrypoint : sh -c 'ls $MY_VAR'
but $MY_VAR
is indeed not resolved.
2) docker inspect CONTAINER
When we inspect the alpine-example container :
docker inspect alpine-example | grep -4 Cmd
The command is also there but we don't still see the env variable value :
"Cmd": [
"sh",
"-c",
"ls $MY_VAR"
],
In fact, we could not see interpolated variables with these docker commands.
While as a trade-off, we could display separately both command and env variables for a container with docker inspect :
docker inspect alpine-example | grep -4 -E "Cmd|Env"
That prints :
"Env": [
"MY_VAR=/var",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"sh",
"-c",
"ls $MY_VAR"
]
A more docker way would be to use the --format
flag of docker inspect
that allows to specify JSON attributes to render :
docker inspect --format '{{.Name}} {{.Config.Cmd}} {{ (.Config.Env) }}' alpine-example
That outputs :
/alpine-example [sh -c ls $MY_VAR] [MY_VAR=/var PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
3) Retrieve the started process from the container itself for running containers
The entrypoint and command executed by docker may be helpful but in some cases, it is not enough because that is "only" a wrapper entrypoint script (.sh
) that is responsible to start the real/core process.
For example when I run a Nexus container, the command executed and shown to run the container is "sh -c ${SONATYPE_DIR}/start-nexus-repository-manager.sh"
.
For PostgreSQL that is "docker-entrypoint.sh postgres"
.
To get more information, we could execute on a running container
docker exec CONTAINER ps aux
.
It may print other processes that may not interest us.
To narrow to the initial process launched by the entrypoint, we could do :
docker exec CONTAINER ps -1
I specify 1
because the process executed by the entrypoint is generally the one with the 1
id.
Without ps
, we could still find the information in /proc/1/cmdline
(in most of Linux distros but not all). For example :
docker exec CONTAINER cat /proc/1/cmdline | sed -e "s/\x00/ /g"; echo
If we have access to the docker host that started the container, another alternative to get the full command of the process executed by the entrypoint is :
: execute ps -PID
where PID is the local process created by the Docker daemon to run the container such as :
ps -$(docker container inspect --format '{{.State.Pid}}' CONTAINER)
User-friendly formatting with docker ps
docker ps --no-trunc
is not always easy to read.
Specifying columns to print and in a tabular format may make it better :
docker ps --no-trunc --format "table{{.Names}}\t{{.CreatedAt}}\t{{.Command}}"
Create an alias may help :
alias dps='docker ps --no-trunc --format "table{{.Names}}\t{{.CreatedAt}}\t{{.Command}}"'