Docker容器启动Postgres 9.5 AS后立即停止问题求助

Hey, I’ve run into similar head-scratching issues with Docker containers vanishing silently before—total pain when you can’t even get logs to clue you in. The good news is that you can manually start Postgres via an interactive shell, which means the core Postgres setup is solid. The problem is almost certainly tied to how the container is configured to launch by default. Let’s break this down step by step.

Common Causes & Fixes #

1. Default Startup Command Isn’t Running Postgres in Foreground #

Docker containers stop the second their main process exits. If your Postgres 9.5 AS image’s default CMD or ENTRYPOINT is launching Postgres in the background (e.g., appending a & to the command), the container will shut down as soon as the startup script finishes running—even if Postgres is still running in the background.

How to check:
First, inspect the image’s default entrypoint and command to see what’s running on startup:

docker inspect <your-postgres-9.5-as-image> | grep -A 10 "Entrypoint"
docker inspect <your-postgres-9.5-as-image> | grep -A 10 "Cmd"

Fix:
Override the default command to launch Postgres in the foreground explicitly when starting the container:

docker run -d -p 5432:5432 \
  -v ./pgdata:/var/lib/postgresql/data \
  <your-postgres-9.5-as-image> \
  postgres -D /var/lib/postgresql/data

This forces Postgres to run as the container’s main foreground process, keeping the container alive.

2. Permissions Issues on the Data Volume #

If you’re mounting a host directory as Postgres’ data volume, incorrect permissions can cause Postgres to fail silently on startup (since it can’t write to the data directory).

How to check:
On your host machine, verify the permissions of your mounted data directory:

ls -ld ./pgdata

Postgres typically runs as a user with UID 999 in official images—if your directory is owned by root or another user, Postgres can’t access it to initialize or write data.

Fix:
Adjust the directory permissions to match the Postgres user in the container:

sudo chown -R 999:999 ./pgdata

If you don’t know the exact UID for the Postgres user in your image, you can check it with:

docker run --rm <your-postgres-9.5-as-image> id postgres

3. Silent Failures in Initialization Scripts #

Some Postgres AS images include custom initialization scripts in /docker-entrypoint-initdb.d/ (like SQL setup scripts or shell scripts). If these scripts fail, the startup process might exit without logging anything.

How to check:
Launch an interactive shell in the container and run the initialization scripts manually to catch errors:

docker run -it --entrypoint sh <your-postgres-9.5-as-image>

Then inside the container:

# Test all initialization scripts one by one
for script in /docker-entrypoint-initdb.d/*; do
  echo "Running script: $script"
  if [ -x "$script" ]; then
    "$script" 2>&1  # Run executable scripts and show errors
  else
    psql -U postgres -f "$script" 2>&1  # Run SQL scripts and show errors
  fi
done

Look for any error messages that might be crashing the startup process.

4. Force Verbose Logging to Catch Silent Errors #

If logs are still empty, force Postgres to output detailed logs to stderr (which Docker captures) with higher verbosity:

docker run -it --rm \
  -v ./pgdata:/var/lib/postgresql/data \
  <your-postgres-9.5-as-image> \
  postgres -D /var/lib/postgresql/data \
  -c log_destination=stderr \
  -c log_min_messages=debug1 \
  -c log_statement=all

This should print every step of the startup process, even if the container exits quickly.

Final Checks #

After trying the above, check the container’s exit code to narrow down the issue:

docker ps -a | grep <container-name-or-id>

• Exit code 0: The main process exited normally (likely a foreground/background launch issue)
• Exit code 1: General error (permissions, initialization script failures)
• Exit code 127: Command not found (invalid entrypoint/cmd configuration)

内容的提问来源于stack exchange，提问作者Gerben Kranenborg