Docker新手求助：重启PostgreSQL容器遇OCI运行时创建失败（容器ID已存在）

Hey there, let's work through this Docker problem step by step—totally get how frustrating it is coming back from vacation to find your dev containers dead and refusing to start. Let's tackle the immediate restart error first, then dig into why your containers exited with code 128.

First: Clear Stuck Container Resources #

That OCI runtime create failed: container with id exist error means Docker still has leftover runtime records for your django-postgres container, even though it shows as exited. Here's how to clean that up:

1. List all containers (including stopped ones) to confirm the container's status and ID:

   docker ps -a
   

   You'll see django-postgres in the list, probably marked as Exited (128).

2. Force-stop and delete the stuck container:

   docker rm -f django-postgres
   

   The -f flag tells Docker to nuke any lingering resources tied to that container ID, which should fix the "id exists" error right away.

Next: Restart (or Recreate) Your PostgreSQL Container #

Now that the stuck container is gone, you can bring your PostgreSQL service back up. If you originally created it with a docker run command, re-run that same command (don't forget to include all your volume mounts, environment variables, and port mappings!). For example:

docker run --name django-postgres -e POSTGRES_PASSWORD=yourdevpass -v ./postgres-data:/var/lib/postgresql/data -p 5432:5432 postgres:latest

If you're using Docker Compose, just run:

docker-compose up -d django-postgres

Digging Into Exit Code 128 #

Exit code 128 usually means the container hit a critical error the second it tried to start. Here are the most common causes to check:

• Host resource exhaustion: While you were away, your VM might have run out of memory or CPU, which killed the containers. Check your host's resources with:

  free -h  # Check available memory
  top       # Check CPU usage and running processes
  

  If resources are tight, you might need to stop other non-essential processes or resize your VM.

• Volume permission issues: If your container uses a host-mounted volume for PostgreSQL data, the directory permissions might have changed (maybe from a system update or another process). PostgreSQL runs as user postgres (UID 999) inside the container, so your host directory needs to be writable by that user. Fix it with:

  chown -R 999:999 /path/to/your/postgres/data/directory
  

• Corrupted PostgreSQL config: If the postgresql.conf or pg_hba.conf files in your data volume got messed up, PostgreSQL won't start. Try renaming the existing config files (as a backup) and let the container create fresh ones:

  mv /path/to/your/postgres/data/directory/postgresql.conf /path/to/your/postgres/data/directory/postgresql.conf.bak
  mv /path/to/your/postgres/data/directory/pg_hba.conf /path/to/your/postgres/data/directory/pg_hba.conf.bak
  

  Then restart the container.

• Port conflict: If another process on your VM is using port 5432 (PostgreSQL's default), the container can't bind to it and will exit immediately. Check for port usage with:

  netstat -tulpn | grep 5432
  

  If something else is using the port, stop that process or change the container's port mapping (e.g., -p 5433:5432 to use host port 5433 instead).

Always Check the Logs! #

If your container still exits after trying the above, check the logs—they'll tell you exactly what went wrong:

docker logs django-postgres

Look for error messages like permission denied, invalid config syntax, or connection failures—those will point you straight to the fix.

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