Container Lifecycle

125 = the docker run command itself failed (bad flag, daemon or image-config error) — no container process ever ran. 126 = the command was found but could not be executed (not executable, bad format). 127 = the command was not found inside the image (typo, missing binary, wrong PATH).

143 means the process was killed by SIGTERM's default action — it ran no shutdown code. 0 means the process caught SIGTERM, shut down on its own terms, and exited successfully. In production you want 0: it proves graceful shutdown actually executed.

The daemon waits an exponentially growing delay between attempts — roughly 100 ms, doubling each time, up to a cap of about a minute — so a crash loop doesn't hammer the host. on-failure:N caps attempts; the delay and the counter reset once the container runs successfully for a short while.

docker pause freezes every process in the container using the kernel's freezer cgroup — no signal is sent, memory stays resident, nothing is scheduled. docker unpause resumes exactly where it left off. Stopping instead signals the process to terminate and frees its memory.

An exited container still exists as an object: its writable layer, logs, config and name are retained so you can inspect or restart it. docker rm deletes it and frees that space; docker rm -f kills a running one first; docker run --rm auto-deletes on exit; docker container prune bulk-removes all stopped containers.

The host's NVIDIA driver is older than the CUDA runtime in the image. Compare the driver version nvidia-smi reports inside the container with the image's CUDA version, then upgrade the host driver or rebuild on an older CUDA base.

Docker's default json-file driver writes container output to an unbounded file on the host with no rotation. Set max-size and max-file on the driver — per container or as a daemon-wide default in /etc/docker/daemon.json — then restart the daemon and recreate containers.

A good probe tests that this instance can serve — a cheap, dedicated endpoint that exercises the serving path — with a tight timeout and a binary that actually exists in the image. It should not test downstream dependencies, do real work, or require credentials, because that turns one dependency outage into every container reporting unhealthy.

Both are VM habits. docker exec gives shell access with no second daemon, no keys in the image and no extra listener. Scheduled work belongs in its own container, run from the same image with a different command, so it has its own logs and exit code.

By default, stopping the daemon stops all running containers; on daemon start they come back only if their restart policy says so. Enabling live-restore in daemon.json leaves containers running while the daemon is down — but only for patch-level daemon upgrades, and not in Swarm mode.

A zombie is a dead process whose exit status no parent has collected with wait(). Orphans are re-parented to PID 1, which must reap them. Application processes running as container PID 1 usually never call wait(), so zombies accumulate and can exhaust the PID table. --init inserts tini as PID 1, which reaps them.

The image's entrypoint runs /docker-entrypoint-initdb.d only when it initializes an empty data directory. With a persistent data volume already initialized, it skips straight to starting the server, so edited scripts never run. Schema changes belong in a migration tool.

Exactly one layer should own restarts. If an outer supervisor starts and stops the container, set the container policy to no — otherwise two supervisors fight, and a workload the outer layer stopped keeps coming back. Docker's policy is for plain single-host deployments.

On SIGTERM: fail readiness first, stop accepting new HTTP connections and stop pulling from the queue, finish or abandon in-flight work under a bounded deadline shorter than the stop timeout, flush and close, exit 0. Set the stop timeout above your worst realistic drain, not above your worst theoretical one.

Docker mounts a 64 MB tmpfs at /dev/shm in every container. Workloads that pass bulk data between processes through POSIX shared memory exhaust it and die with a bus error rather than a clear message. Raise it with --shm-size.

docker run accepts --health-cmd, --health-interval, --health-timeout, --health-retries and --health-start-period to define or retune a probe, and --no-healthcheck to disable one entirely. Use them to tune against a real workload, or to override a base image's unsuitable check.

When you want a pinned tool version per project without installing it: docker run --rm starts a published image, runs one command against a mounted directory, then disposes of the container. Files it writes are owned by the user it ran as.

docker diff CONTAINER lists every path that differs from the container's image, prefixed A for added, C for changed and D for deleted. It shows no sizes, no file contents, and nothing under a volume or bind mount — so a disk problem in mounted storage is invisible to it.

dead means the daemon started tearing the container down and could not finish — usually a stuck mount or storage-driver error. The container cannot be started. Try docker rm -f; if that fails, find and unmount the leftover mounts under /var/lib/docker, then remove again, restarting the daemon if necessary.

Rarely, and on conditions: when two concerns share a lifetime and a failure domain and the coupling cannot cross a container boundary, or when consuming a vendor image with its own process manager. Then demand signal forwarding, a non-zero exit on child failure, and stdout logging.