Bug Report: Fresh Docker-Compose Deployment Fails Due to Container Migration Race Conditions and File Permissions
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- docker-compose, yaml
- Domain
- devops, infrastructure
Research direction
Read the official Docker Compose file, especially the depends_on entries for the web, worker, and cron services, and check how the seeder service runs migrations. Confirm the startup order in a fresh deployment using the reproduction steps in the issue. Done when those services wait for the seeder to exit successfully and a fresh deployment starts without migration collisions.
Written by the indexing model from the issue text.
Description
When initiating a brand new deployment using the official OpenProject Docker Compose file, the installation falls into an infinite boot/restart loop. The core issues stem from a startup race condition where multiple containers concurrently attempt to run initial database migrations.
Migration Race Condition
Because web, worker, and cron services treat depends_on: - seeder as satisfied the moment the seeder container starts (rather than when it completes successfully), all application containers hit the blank database concurrently. They simultaneously attempt to execute db:migrate, colliding on table creation rules
PG::DuplicateTable: ERROR: relation "announcements" already exists
Resolution / Workaround
To successfully complete a fresh deployment, the initial boot sequence must be completely isolated
Force the database cluster to fully generate its baseline schemas before the web app workers compete for traffic:
docker compose down -v
docker compose up db -d # Allow DB to output "ready to accept connections"
docker compose up seeder # Wait for seeder process to cleanly exit with code 0
docker compose up -d # Bring up the rest of the stack safely
Suggested Fix for docker-compose.yml
Update the depends_on conditions for the web, worker, and cron services to enforce waiting until the database schema generation completes successfully:
depends_on:
db:
condition: service_started
cache:
condition: service_started
seeder:
condition: service_completed_successfully
- Dominant language
- Shell
- Stars
- 347
- Forks
- 319
- PR merge metrics
- No merged PRs in 30d
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from opf/openproject-docker-compose
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
opf/openproject-docker-compose#150 · 6 comments · 5 reactions ·
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
-
SSFR white listOpen
Difficulty 3/5 1-2 days Newbie friendliness 42/100
opf/openproject-docker-compose#161 · 2 comments ·
All issues in opf/openproject-docker-compose
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
area/dev-infra area/reliability area/tests
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
agent-substrate/substrate#3461 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
pypa/advisory-database#412 ·
Maintainers usually reply within 1 day
-
GEFSv12
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 2 days