Manage Docker Containers Safely from the Command Line

You will finish with a small, repeatable workflow for finding containers, checking their state, reading their output, and stopping or removing one without guessing. The examples use Docker CE CLI 29.8.1, installed from the docker-ce-cli package version 5:29.8.1-1~ubuntu.24.04~noble. Allow about 15 minutes. You need a shell, a working Docker daemon, and permission to use it. Commands that only inspect local state are ordinary user commands, although your Docker installation may require membership of its access group or sudo.

1. Check the command and daemon

The manpage describes docker container as the command group for managing containers. It has no useful action by itself, so always add a subcommand such as ls, inspect, logs or run. Confirm the client and the command vocabulary before following a copied example:

$ docker version --format '{{.Client.Version}}'
29.8.1
$ docker container --help
Usage:  docker container COMMAND

Manage containers

Checkpoint: if the version command fails, fix Docker access before changing a container. A message about permission usually means your user cannot reach the Docker socket. A message about the daemon being unavailable is a service or context problem. Do not solve either by adding sudo blindly; first check which Docker context and socket your machine is meant to use.

2. List what is running

Start with the read-only view. docker container ls shows running containers by default. The aliases docker container ps and docker ps are equivalent, but keeping the full command makes the object being managed clear:

$ docker container ls
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

Your columns may contain rows and values that differ from this empty example. To include stopped containers, add --all:

$ docker container ls --all
CONTAINER ID   IMAGE          COMMAND       CREATED          STATUS                     PORTS     NAMES
abc123...      example/image  "..."         2 minutes ago    Exited (0) 1 minute ago              example-job

Container IDs and names are identifiers, not descriptions. Copy the exact name or a sufficiently specific ID into later commands. If the table is too wide, use --format; for scripts, --quiet prints IDs only:

$ docker container ls --all --quiet
abc123...

3. Inspect one container before acting

Use inspect when a status line is not enough. It displays detailed configuration and runtime state and accepts one or more container names or IDs:

$ docker container inspect example-job
[
    {
        "Id": "abc123...",
        "Name": "/example-job",
        "State": {
            "Status": "exited",
            "ExitCode": 0
        }
    }
]

The complete JSON is longer than this excerpt. For a focused check, ask Docker to format one field:

$ docker container inspect --format '{{.State.Status}} {{.State.ExitCode}}' example-job
exited 0

Do not treat an exit code of zero as proof that an application did all the work you expected. It only describes the process exit recorded by Docker. Inspect the image, command, mounts, environment and restart policy before restarting a failed workload.

4. Run a disposable test container

run creates a container and starts its configured process. It needs an image, and it may pull that image from a registry. Use --rm for a deliberate throwaway check so Docker removes the container after the process exits:

$ docker container run --rm hello-world
Hello from Docker!
Your installation appears to be working correctly.

The exact informational text can change with the image version. The useful checkpoint is a successful exit and the absence of a leftover container:

$ docker container ls --all --filter ancestor=hello-world
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

This command can download an image and sends the image's output to your terminal. Read the image source and tag before running an unfamiliar image. Avoid --privileged, host filesystem mounts, host networking and host PID options unless you have a specific, reviewed reason: they can substantially weaken isolation.

5. Read logs and check live processes

For a named container that is already running, use logs to read what its main process wrote:

$ docker container logs --tail 50 --timestamps CONTAINER_NAME
2026-09-23T10:20:00.000000000Z service started

Replace CONTAINER_NAME with the identifier from ls. The timestamp and content are application-specific. Use --follow only when you want a live stream, and stop it with Ctrl-C; that interrupts log viewing, not the container.

To see the processes Docker can report inside the container, run:

$ docker container top CONTAINER_NAME
UID   PID   PPID   C   STIME   TTY   TIME   CMD
root  ...   ...    0   ...     ?     ...    ...

Process output depends on the image and host runtime. An empty or unavailable process view is not necessarily an application failure. Use logs and inspect together when diagnosing a restart loop.

6. Stop, start and restart deliberately

Stopping is a state change. Warn anyone using the service, check its dependencies, and confirm the name before running it. The normal stop command asks the container process to exit and waits for the configured timeout:

$ docker container stop CONTAINER_NAME
CONTAINER_NAME

Verify the result rather than assuming the printed name means the application shut down cleanly:

$ docker container inspect --format '{{.Name}} {{.State.Status}} {{.State.ExitCode}}' CONTAINER_NAME
/CONTAINER_NAME exited 0

Start that stopped container again with docker container start CONTAINER_NAME. Use restart when you intentionally want Docker to stop and then start it. These commands preserve the container object, its writable layer and its attached volumes. If stopping does not complete, investigate the process and timeout before using forceful removal.

7. Remove only what you have identified

Removing a container is destructive to that container object. Its writable container layer is discarded. Stop it first, record any logs or configuration you need, and check the identifier one more time:

$ docker container rm CONTAINER_NAME
CONTAINER_NAME
$ docker container ls --all --filter name=CONTAINER_NAME
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

The ordinary remove command refuses a running container. docker container rm --force kills and removes one, so reserve it for an understood incident. --volumes also removes anonymous volumes associated with the container. Do not add it as a tidy-up habit, and do not assume named volumes are disposable: identify the volume and its data-retention policy first.

There is no undo command for a removed container. Recovery means recreating it from the original image, command, environment, mounts and network configuration. Keep those inputs in a compose file, deployment definition or documented command rather than relying on an inspect result after deletion.

8. Prune stopped containers carefully

docker container prune removes all stopped containers, not just the one you were investigating. Treat it as a batch deletion. Review the stopped list and any retention requirement first:

$ docker container ls --all --filter status=exited
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS                     PORTS     NAMES
abc123...      example   "..."     1 hour ago Exited (0) 55 minutes ago           old-job

Without --force, prune asks for confirmation. A filter such as --filter until=24h can narrow the age range, but still review what it selects. Do not use --force in a pasted maintenance command unless the deletion scope is explicit and approved. Removed containers cannot be restored by Docker.

Common traps

• Only seeing running containers: add --all before concluding that a container does not exist.
• Using a stale name: names are assigned per container. Re-run ls --all after a deployment or recreation.
• Confusing image and container: run creates a container from an image. Removing the container does not remove the image.
• Following logs forever: logs --follow is an attached viewer. Use Ctrl-C to leave it.
• Adding privileges to make a command work: diagnose socket access, mounts, capabilities and the image command separately. More privilege can hide the real fault and increase impact.