New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dependency failed to start: container for service "web" is unhealthy #67
Comments
I don't know the docker-compose setup. But starting up the wger container takes a long time especialy on lower end hardware. As i'm running it on raspberry pi's and similar i had to do some tweaks. For GUNICORN_CMD_ARGS="--timeout 240 --workers=2" A other idea would be to also disable the |
Hi! Do you get some error in the logs when opening the application? (in the web service) I just started a new instance with the default compose and conf file and everything booted up nicely:
Somebody else had the problem that the application tried to setup the database before it was ready so some things were missing. What helped them was to drop the db volume, start the db service manually first and then all the rest (this only this first initial run, later it's not important) |
First of all, thank you for responding. When I deleted the volume entry at the db service in the compose, and start the db service manually I have the same issue. @bbkz I don't think it is a problem based on lower end hardware. However I tried to add that env entry |
When I removed the healthcheck dependency for the celery_worker, I produced a log for that container, maybe this might help troubleshooting: But okay, when I restored back to the first compose file. I altered the prod.env for the debugging mode DJANGO_DEBUG=True Request Method: GET Django Version: 4.1.9 Traceback (most recent call last): Exception Type: DoesNotExist at /en/software/terms-of-service |
yes the gymconfig stuff, that definitely means that the database wasn't initialised properly. sorry, I didn't mean that you remove the volume from the compose file, just to delete the volume itself and start the service manually, so like this
(also you should get a medal for all the logs you provide!) |
thank you! I expected providing as much as possible might be the best to troubleshoot :) nginx: db: cache: celery_worker: celery_beat: volumes: networks: Now I can find the db volume, and it holds files and folders! So that is some progress. Now the website looks like this, and I think this is more familiar to you: I will check whether all features work another time, maybe tonight and update you. However, where should I look to really know it all works according to plan? |
the volumes are handled by docker and are stored... somewhere, but solve a lot problems with things like permissions etc. You can inspect a volume with You can download the exercise images with |
@clone3448 I had a similar problem. It turns out the first time wger starts, it does some extra setup things that require a bit more time. If it does not finish within the healthcheck interval of 5*10s, it fails the healthcheck with state unhealty. Docker provides an option for such a situation called |
The first time Wger starts, it does some extra setup things that require a bit more time to finish before the health check calls it quits. This commit adds a reasonable warmup period before it starts to enforce the health checks. It addresses wger-project#67.
FYI the PR with the start period is merged, hopefully this fixes it |
Hi, just curious: you mentioned you need to add that |
Good day, I tried to deploy the production docker compose image on the container manager on my synology ds923+ but got the error: dependency failed to start: container for service "web" is unhealthy.
I have altered the compose provided on github a bit to this (mainly the volumes):
`services:
web:
image: wger/server:latest
container_name: wger_server
depends_on:
db:
condition: service_healthy
cache:
condition: service_healthy
env_file:
- /volume1/docker/wger/config/prod.env
volumes:
- static:/home/wger/static
- media:/home/wger/media
expose:
- 8000
healthcheck:
test: wget --no-verbose --tries=1 --spider http://localhost:8000
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
nginx:
image: nginx:stable
container_name: wger_nginx
depends_on:
- web
volumes:
- /volume1/docker/wger/config/nginx.conf:/etc/nginx/conf.d/default.conf
- static:/wger/static:ro
- media:/wger/media:ro
ports:
- "8001:80"
healthcheck:
test: service nginx status
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
db:
image: postgres:15-alpine
container_name: wger_db
environment:
- POSTGRES_USER=wger
- POSTGRES_PASSWORD=wger
- POSTGRES_DB=wger
volumes:
- postgres-data:/var/lib/postgresql/data/
expose:
- 5432
healthcheck:
test: pg_isready -U wger
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
cache:
image: redis
container_name: wger_cache
expose:
- 6379
volumes:
- redis-data:/data
healthcheck:
test: redis-cli ping
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
celery_worker:
image: wger/server:latest
container_name: wger_celery_worker
command: /start-worker
env_file:
- /volume1/docker/wger/config/prod.env
volumes:
- media:/home/wger/media
depends_on:
web:
condition: service_healthy
healthcheck:
test: celery -A wger inspect ping
interval: 10s
timeout: 5s
retries: 5
celery_beat:
image: wger/server:latest
container_name: wger_celery_beat
command: /start-beat
volumes:
- celery-beat:/home/wger/beat/
env_file:
- /volume1/docker/wger/config/prod.env
depends_on:
celery_worker:
condition: service_healthy
volumes:
postgres-data:
celery-beat:
static:
media:
redis-data:
networks:
default:
name: wger_network`
Furthermore the nginx.conf is not altered, and the prod.env is only altered with the SECRET_KEY and SIGNING_KEY.
I can access the website, which looks like this:
The wger_server docker container seems to be not working correctly, looking in the log I see the following:
After thousands of items being deleted, I get this:
The other docker containers seem to not have a lot of issues in the log, except wger_celery_worker
The console terminal of the entire stack looks like this:
What is going wrong in my configurations and how can I deal with it? First time I am using databases in a docker compose file.
The text was updated successfully, but these errors were encountered: