Common container startup failures in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Identify the error from Docker container startup logs

You run a Docker container but it immediately stops. You check the logs with docker logs container_id and see this message:

standard_init_linux.go:228: exec user process caused: no such file or directory

What is the most likely cause of this error?

A The command specified as ENTRYPOINT or CMD does not exist inside the container.

B The container ran out of memory during startup.

C The Docker daemon is not running on the host machine.

D The container image is corrupted and cannot be loaded.

💡 Hint

Think about what the error means about the process Docker tries to start.

This error means Docker tried to run a command that is missing inside the container. It usually happens if the ENTRYPOINT or CMD points to a file that is not present or has wrong path.

💻 Command Output

intermediate

Diagnose container exit code after startup failure

You start a container and it exits immediately. Running docker ps -a shows the container exited with code 137.

What does exit code 137 usually indicate?

A The container failed due to a syntax error in the Dockerfile.

B The container was killed because it ran out of memory (OOM).

C The container completed successfully and exited normally.

D The container was stopped manually by the user.

💡 Hint

Exit code 137 is 128 + 9, where 9 is the SIGKILL signal.

Exit code 137 means the container process was killed by signal 9 (SIGKILL), often caused by the system killing it due to out-of-memory conditions.

❓ Troubleshoot

advanced

Resolve Docker container failing due to port binding error

You try to start a container with docker run -p 80:80 myapp but get this error:

Bind for 0.0.0.0:80 failed: port is already allocated

What is the best way to fix this issue?

A Restart the Docker daemon to clear port bindings.

B Rebuild the container image to use a different internal port.

C Stop the process currently using port 80 on the host or use a different host port for the container.

D Increase the container's memory limit to allow port binding.

💡 Hint

Port conflicts happen when two processes want the same port on the host.

Port 80 on the host is already in use by another process. You must free that port or map the container port to a different host port.

✅ Best Practice

advanced

Prevent container startup failure due to missing environment variables

Your containerized app requires environment variables to start properly. Sometimes the container fails immediately with configuration errors.

Which practice helps avoid startup failures caused by missing environment variables?

A Use Docker Compose or Kubernetes manifests to define required environment variables explicitly.

B Start the container without environment variables and set them later inside the container.

C Ignore environment variables and rely on default app settings only.

D Hardcode environment variables inside the container image during build.

💡 Hint

Think about how to ensure environment variables are always set before container starts.

Defining environment variables explicitly in deployment files ensures they are always provided when the container starts, preventing configuration errors.

🔀 Workflow

expert

Order the steps to debug a container that fails immediately after starting

You have a container that starts and then stops immediately. Put the following debugging steps in the correct order to find the root cause:

A 3,1,4,2

B 1,4,3,2

C 1,3,4,2

D 4,1,3,2

💡 Hint

Start with quick info about exit code, then logs, then config, then interactive inspection.

First check exit code to understand failure type, then logs for error messages, then Dockerfile for config issues, finally run interactively to explore environment.

Practice

1. What is a common reason a Docker container might fail to start immediately after running docker run?

easy

A. The container tries to use a port already in use on the host

B. The Docker daemon is running

C. The container image is very large

D. The host has enough free disk space

Solution

1. Step 1: Understand port conflicts in Docker

   If a container tries to bind to a port already used by another process on the host, it cannot start because the port is busy.

2. Step 2: Check other options for relevance

   Options B, C, and D do not prevent container startup immediately; only port conflict causes failure here.

3. Final Answer:

   The container tries to use a port already in use on the host -> Option A

4. Quick Check:

   Port conflict = container startup failure [OK]

Hint: Check if the port is free before starting container [OK]

Common Mistakes:

• Assuming large image size stops container start
• Thinking Docker daemon running causes failure
• Ignoring port conflicts

2. Which of the following docker run commands will correctly set an environment variable named APP_ENV to production?

easy

A. docker run --env APP_ENV production myimage

B. docker run -e APP_ENV production myimage

C. docker run -env APP_ENV=production myimage

D. docker run -e APP_ENV=production myimage

Solution

1. Step 1: Recall correct syntax for environment variables

   The correct flag is -e or --env followed by VAR=VALUE without spaces.

2. Step 2: Analyze each option

   docker run -e APP_ENV=production myimage uses correct syntax: -e APP_ENV=production. Options A, C, and D have syntax errors or missing '=' sign.

3. Final Answer:

   docker run -e APP_ENV=production myimage -> Option D

4. Quick Check:

   Use -e VAR=VALUE for env vars [OK]

Hint: Use -e VAR=VALUE with no spaces for env vars [OK]

Common Mistakes:

• Omitting '=' between variable and value
• Using incorrect flag like -env
• Adding spaces between variable and value

3. Given this command:

docker run -p 8080:80 nginx

What will happen if port 8080 on the host is already used by another service?

medium

A. Docker will automatically choose a different host port

B. The container will fail to start with a port binding error

C. The container will start normally and ignore the port conflict

D. The container will start but the service inside will not work

Solution

1. Step 1: Understand port binding behavior

   If the host port (8080) is already in use, Docker cannot bind the container port to it, causing failure.

2. Step 2: Evaluate other options

   Docker does not auto-select ports unless specified with -P. The container won't start ignoring conflicts or silently fail.

3. Final Answer:

   The container will fail to start with a port binding error -> Option B

4. Quick Check:

   Port in use causes start failure [OK]

Hint: Check host ports before binding with -p [OK]

Common Mistakes:

• Assuming Docker auto-changes ports
• Thinking container starts ignoring conflicts
• Believing service inside fails but container runs

4. You run a container with docker run -v /host/data:/app/data myimage but the container fails to start. What is the most likely cause?

medium

A. The image name is incorrect

B. The container does not have enough CPU resources

C. The host directory /host/data does not exist or has wrong permissions

D. The Docker daemon is not running

Solution

1. Step 1: Understand volume mount requirements

   Docker requires the host directory to exist and be accessible for volume mounts; otherwise, container startup fails.

2. Step 2: Check other options

   Incorrect image name causes image pull errors, not volume mount failure. CPU or daemon issues cause different errors.

3. Final Answer:

   The host directory /host/data does not exist or has wrong permissions -> Option C

4. Quick Check:

   Volume mount fails if host path missing [OK]

Hint: Verify host path exists and permissions before mounting [OK]

Common Mistakes:

• Ignoring host directory existence
• Confusing image name errors with volume errors
• Assuming CPU limits cause mount failures

5. You have a container that fails immediately after starting. You run docker logs container_id and see an error about a missing environment variable DB_HOST. How should you fix this?

hard

A. Add -e DB_HOST=value to the docker run command

B. Increase the container's CPU and memory limits

C. Change the container image to a different one

D. Restart the container without changes

Solution

1. Step 1: Interpret the error message from logs

   The logs indicate the container expects an environment variable DB_HOST which is missing, causing failure.

2. Step 2: Provide the missing environment variable

   Use -e DB_HOST=value in the docker run command to supply the required variable.

3. Step 3: Understand why other options fail

   Restarting without changes won't fix missing vars. Changing image or resources doesn't address environment variables.

4. Final Answer:

   Add -e DB_HOST=value to the docker run command -> Option A

5. Quick Check:

   Missing env var fixed by -e flag [OK]

Hint: Use docker logs to find missing env vars, then add -e [OK]

Common Mistakes:

• Restarting without fixing environment variables
• Changing image unnecessarily
• Increasing resources instead of fixing config