External/SnapOtter
1
0
Fork 0
mirror of https://github.com/snapotter-hq/SnapOtter.git synced 2026-08-03 07:46:42 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs(deployment): troubleshoot the off-network EAI_AGAIN crash-loop (#688)

Browse Source 
A retried compose up after a failed first start can leave the app container detached from the compose network; the resulting Postgres EAI_AGAIN crash-loop reads as a database problem and never self-heals. New Troubleshooting section with the force-recreate fix. Fixes #675.
This commit is contained in:
SnapOtter
2026-07-30 10:17:43 +08:00
committed by GitHub
parent 2d39881d16
commit 53cb9d0c70
1 changed files with 18 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
apps/docs/guide/deployment.md
+18
View File
@@ -561,6 +561,24 @@ cloudflared tunnel --url http://localhost:1349
Note: Cloudflare has a 100 MB upload limit on free plans. Set `MAX_UPLOAD_SIZE_MB=100` to match.
## Troubleshooting {#troubleshooting}
### "Postgres not reachable: EAI_AGAIN" right after a failed first start {#eai-again-after-failed-first-start}
If the very first `docker compose up -d` fails partway (a port already in use is the usual reason), a plain `up -d` retry can start the app container without attaching it to the compose network. The app then crash-loops with:
```
Postgres not reachable: EAI_AGAIN
```
while `docker ps` shows postgres healthy. The error is real but points at the wrong container: without the network, DNS for the `postgres` hostname cannot resolve at all, and the restart policy replays the same failure forever.
Fix whatever broke the first start (usually: free the port), then force the app container to be recreated so it reattaches to the network:
```bash
docker compose up -d --force-recreate SnapOtter
```
## CI/CD {#ci-cd}
The GitHub repository has three workflows: