Home / Alt manpages / docker-start(1)

  • docker-start(1)
  • User command
  • linux

Restart a Stopped Container with docker start

The container exited overnight, and you want it back with its data and config intact, without rebuilding anything. This guide uses docker start to revive an existing container, confirm it is running, and choose between watching its output or leaving it in the background. It takes about ten minutes. The command does not create a new container or rebuild the image: it reuses the container's existing configuration and writable layer.

What you need:

  • Docker CLI access.
  • An existing container. Its name or ID will do.
  • A container you recognise. Starting one can expose a service or consume host resources.

The examples were checked with Docker CLI 29.8.1 from docker-ce-cli version 5:29.8.1-1~ubuntu.24.04~noble.

1. Check the installed command

First confirm the CLI version and the local option set. These are read-only commands and normally need no elevated privileges:

$ docker version --format '{{.Client.Version}}'
29.8.1
$ docker start --help
Usage:  docker start [OPTIONS] CONTAINER [CONTAINER...]

Start one or more stopped containers

docker start is an alias for docker container start. The two forms use the same arguments. The installed help matters when a vendor package differs from the local manpage, especially for experimental options.

Checkpoint

If the first command reports a daemon or permission error, fix Docker access before choosing a container. Do not jump to sudo as a way to hide an incorrect container name. On a host where Docker is deliberately restricted, ask the administrator for the approved access method.

2. Find a stopped container

List all containers, including stopped ones. This only inspects Docker state:

$ docker ps -a --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'
CONTAINER ID   NAMES          STATUS
8f31c9e8f4d1   reports-db     Exited (0) 2 hours ago
4a6d1e7c91b2   reports-web    Up 2 hours
  • Pick by name or ID. A name such as reports-db works, and so does its ID.
  • Status starting with Up means it is already running, so starting it again is unnecessary.
  • Empty list. docker start cannot help, because it only starts containers that already exist. Use docker create or docker run as a separate workflow when you genuinely need a new one.

Do not confuse an image with a container. Image names such as postgres:16 are not valid substitutes for a container name unless a container was created with that name. Inspect a candidate before starting it if its purpose is unclear:

$ docker inspect --format '{{.Name}} {{.State.Status}}' reports-db
/reports-db exited

3. Start it in the background

Start the selected container by name:

$ docker start reports-db
reports-db
$ docker ps --filter name='^/reports-db$' --format 'table {{.Names}}\t{{.Status}}'
NAMES       STATUS
reports-db  Up 3 seconds

Without --attach, Docker prints the container name or ID and returns control to your shell. The program inside keeps running in the background. Uptime and health text vary, and a health check can stay starting after the container itself is up.

Warning

This changes runtime state and may start a database, web server or other exposed service. It does not need sudo when your account can already run Docker. If access is denied, stop and resolve the Docker socket or group policy with the machine owner rather than adding privileges casually.

4. Verify the process and service state

A successful start only tells you that Docker accepted the request. Check the state that matters to your task:

$ docker inspect --format 'status={{.State.Status}} running={{.State.Running}} exit={{.State.ExitCode}}' reports-db
status=running running=true exit=0
$ docker logs --tail 20 reports-db
database system is ready to accept connections

Log output depends on the image and its logging driver, so the last line above is an example, not a guaranteed message.

  • HTTP service. Verify the published endpoint from a suitable client.
  • Database. Use the application's own health check or a harmless connection test.
  • Running is not ready. A container can be running while its application is still initialising or failing its health check.

If the container stops again, inspect its last state and logs before repeatedly starting it:

$ docker inspect --format 'status={{.State.Status}} exit={{.State.ExitCode}} error={{.State.Error}}' reports-db
status=exited exit=1 error=
$ docker logs --tail 50 reports-db

Tip

Repeated starts are not a repair. The process may have a bad configuration, a missing mount, a failed dependency or an application error.

5. Attach only for live output

Use --attach, or its short form -a, when you want Docker to connect your terminal to the container's standard output and error streams while it starts:

$ docker start --attach reports-web
web server listening on 0.0.0.0:8080

This can keep your terminal occupied for as long as the container's main process runs. The option forwards signals, so interrupting the attached session can affect the container.

If you only need logs from a container already running in the background, use docker logs --follow reports-web instead. Detach from that log stream with your terminal's normal interrupt or end-of-follow action; do not stop the container unless that is your intention.

Add --interactive, or -i, when the container's standard input must stay open. It is usually relevant to an interactive container, not a detached service. Neither option gives you a shell inside the container; use docker exec for a command in an already running container.

6. Handle failures without changing more than necessary

A missing or misspelled container name is a lookup failure. Recheck the list and inspect the exact name:

$ docker start reports-dbb
Error response from daemon: No such container: reports-dbb
$ docker ps -a --format '{{.Names}}'
reports-db

Error wording can vary, but the useful facts are the name Docker looked up and the non-zero exit status. Correct the reference rather than creating a similarly named container.

  • Already running. Verify with docker ps and move on to application checks.
  • Cannot connect to the daemon. Check the Docker service and the socket using your system's normal administration procedure. Starting a container cannot repair a stopped daemon.
  • Checkpoint options. The manpage also documents --checkpoint and --checkpoint-dir for restoring from a checkpoint. These are specialised, experimental daemon features, not a general way to recover a failed container. The local 29.8.1 command help does not list them, so do not add them to a routine command unless your Docker build and daemon explicitly support the workflow.

7. Stop it again when the test is over

Starting a container has no undo flag. If you started it only for a test and it is safe to stop the service, record its previous state first and then stop it explicitly:

$ docker inspect --format '{{.Name}} {{.State.Status}}' reports-db
/reports-db running
$ docker stop reports-db
reports-db
$ docker inspect --format '{{.Name}} {{.State.Status}}' reports-db
/reports-db exited

Warning

docker stop is service-disrupting: it asks the main process to exit and may wait before forcing termination. Do not run it against a production database or other shared service merely to tidy up a tutorial.

Stopping does not remove the container or its volumes. Removing a container later is a separate, potentially destructive action.

Done means

  • Right container. You confirmed the installed Docker CLI and selected an existing container by exact name or ID.
  • Started cleanly. docker start returned successfully and the container reached the state you expected.
  • Readiness checked. You looked at application readiness rather than relying only on running=true.
  • Attach used sparingly. You used attachment and interactive input only when the container required them.
  • Quick exit diagnosed. You read its state and logs instead of retrying blindly.
  • End state decided. You know whether the container should keep running, or stopped it deliberately after the test.