Hi there! New Gramps user here. I’ve been playing arounds with Gramps Web locally the past few weeks, it seems like a great piece of software! I’m looking to deploy it to share with my family and ran into a couple issues when deploying it to an EC2 instance on AWS. For context, I’m a professional full-stack software engineer.
I’ve followed the steps from the docs here Docker with Let's Encrypt - Gramps Web, using the content of the linked docker-compose.yml and nginx_proxy.conf files, adding in my values for the VIRTUAL_HOST
, LETSENCRYPT_HOST
, and LETSENCRYPT_EMAIL
environment variables.
On a new, small EC2 instance (2 vCPUs and 2GB RAM), I installed Docker, made a new directory, created those two config files and then ran docker compose up -d
. Everything starts to run for 5-10 seconds, as seen via the logs (docker compose logs -f
), but then the machine locks up. The log output stops, keyboard input stops being received, and eventually the SSH connection drops. I can’t log back into the machine without rebooting it through AWS, and sometimes the machine is so deadlocked the reboot command isn’t even received; I have to stop and start the instance entirely. After I manage to get access to the machine and start the docker containers again, the machine locks up again. I’ve tried this a few times, reusing the same instance and making a new EC2 instance, and I’ve gotten the same result each time.
These are the last logs I see before the output stops:
docker logs output
grampsweb_celery | [2025-01-12 18:17:26,500: INFO/MainProcess] Connected to redis://grampsweb_redis:6379/0
grampsweb_celery | [2025-01-12 18:17:26,500: WARNING/MainProcess] /usr/local/lib/python3.11/dist-packages/celery/worker/consumer/consumer.py:508: CPendingDeprecationWarning: The broker_connection_retry configuration setting will no longer determine
grampsweb_celery | whether broker connection retries are made during startup in Celery 6.0 and above.
grampsweb_celery | If you wish to retain the existing behavior for retrying connections on startup,
grampsweb_celery | you should set broker_connection_retry_on_startup to True.
grampsweb_celery | warnings.warn(
grampsweb_celery |
grampsweb_celery | [2025-01-12 18:17:26,506: INFO/MainProcess] mingle: searching for neighbors
nginx-proxy-acme | [Sun Jan 12 18:17:27 UTC 2025] Getting webroot for domain='family.REDACTED.com'
nginx-proxy-acme | [Sun Jan 12 18:17:27 UTC 2025] Verifying: family.REDACTED.com
grampsweb_celery | [2025-01-12 18:17:27,517: INFO/MainProcess] mingle: all alone
grampsweb_celery | [2025-01-12 18:17:27,529: INFO/MainProcess] celery@0db449d1b4f3 ready.
grampsweb | [2025-01-12 18:17:27 +0000] [12] [INFO] Starting gunicorn 23.0.0
grampsweb | [2025-01-12 18:17:27 +0000] [12] [INFO] Listening at: http://0.0.0.0:5000 (12)
grampsweb | [2025-01-12 18:17:27 +0000] [12] [INFO] Using worker: sync
grampsweb | [2025-01-12 18:17:27 +0000] [13] [INFO] Booting worker with pid: 13
grampsweb | [2025-01-12 18:17:27 +0000] [14] [INFO] Booting worker with pid: 14
grampsweb | [2025-01-12 18:17:27 +0000] [15] [INFO] Booting worker with pid: 15
grampsweb | [2025-01-12 18:17:27 +0000] [16] [INFO] Booting worker with pid: 16
grampsweb | [2025-01-12 18:17:27 +0000] [17] [INFO] Booting worker with pid: 17
grampsweb | [2025-01-12 18:17:27 +0000] [18] [INFO] Booting worker with pid: 18
grampsweb | [2025-01-12 18:17:27 +0000] [19] [INFO] Booting worker with pid: 19
grampsweb | [2025-01-12 18:17:27 +0000] [20] [INFO] Booting worker with pid: 20
nginx-proxy-acme | [Sun Jan 12 18:17:27 UTC 2025] Pending. The CA is processing your order, please wait. (1/30)
nginx-proxy-acme | [Sun Jan 12 18:17:30 UTC 2025] Pending. The CA is processing your order, please wait. (2/30)
nginx-proxy-acme | [Sun Jan 12 18:17:33 UTC 2025] Pending. The CA is processing your order, please wait. (3/30)
grampsweb boots 8 workers, so my hunch is that those workers are running into some sort of resource contention. Why is this happening and what can I do to stop it from happening? What other logs or traces can I gather to get more detailed information about what’s happening?
Also, this line in the set up instructions
On first run, the app will display a first-run wizard
This does not happen. Maybe that’s the culprit, something’s locked waiting on terminal input? I’m not sure where that first-run wizard is supposed to appear since the containers in the background with the -d
option to docker compose up
.