Diagnosing Immediate Exit in Docker Compose with Log Tail and Since Filters

1. Which --tail / --since combo captures the error?

When a container dies before it has a chance to write to stdout/stderr, docker compose logs will return an empty stream. The trick is to pull the logs while the container is still present and to limit the amount of older context you pull.

1. Use a narrow --tail: --tail=100 is usually enough to see the last 100 lines, which is where a startup failure will appear.
2. Use a recent --since: --since=1m (or --since=5m if you suspect the failure is a few minutes old) limits the log to the last minute. Docker accepts RFC3339 timestamps or relative values like 1m, 30s, etc.
3. Combine them:

   docker compose logs  --tail=100 --since=1m
   

4. If the service restarts rapidly, add --follow to watch the stream until the process exits:

   docker compose logs  --tail=100 --since=1m --follow
   

These flags give you the freshest log slice without pulling the entire history, which is especially useful when the container exits within seconds.

2. Do log rotation options guarantee the lines stay after docker compose down?

In a Compose file you can configure the json-file driver like this:

services:
  myapp:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

These options keep up to three rotated log files on disk while the container exists. However, when you run docker compose down, Docker removes the container and its log files from /var/lib/docker/containers. Therefore, rotation does not preserve logs after removal. To keep logs, you must either avoid removing the container or redirect logs to an external system (e.g., syslog, fluentd). The safest approach is to capture the logs with docker compose logs (or docker logs) before running down.

3. Can docker compose exec <service> env reliably confirm a missing variable?

If the container has already exited, docker compose exec will fail with “no such container” or “is not running.” In that case, the command isn’t reliable. You have two options:

• Inspect the environment before the exit: Start the service with an intentional sleep 60 or tail -f /dev/null in the entrypoint, then run docker compose exec to print env.
• Use docker inspect: docker inspect -f '{{range .Config.Env}}{{println .}}{{end}}' $(docker compose ps -q ) lists the variables that were actually passed to the container at launch time, regardless of whether the process is still running.

Both methods let you confirm that a variable is missing before the process crashes. If you need to see the exact error message produced by the application, capture the logs immediately after the container starts, as described in Question 1.

Missing Diagnostic Detail

To fine‑tune the log‑capture strategy, it helps to know the container’s exit code. Run:

docker ps -a --filter "name=" --format "{{.ID}} {{.Status}}"

The exit code (e.g., 0 for success, non‑zero for failure) can indicate whether the process terminated normally or due to an error, which in turn informs whether you should look for a startup exception or a health‑check failure.