Question
Forgejo and PostgreSQL: Connection Initialization Behavior
Ira River
0 reputation · 12 Jan 2024, 21:43 UTC
56K views1
Loading…
0 reputation · 12 Jan 2024, 21:43 UTC
When starting Forgejo, the application attempts to connect to its configured database. If the initial connection fails, the log records a '[ERROR] Failed to initialize database' message, but it is not clear whether Forgejo will make additional connection attempts before terminating or whether it relies on external restart mechanisms.
Understanding the retry behavior is important for designing resilient deployments, especially in environments where the database may be temporarily unavailable during startup (e.g., cloud‑managed instances with delayed readiness probes).
Does Forgejo retry the database connection automatically? If so, what is the number of attempts and the interval between them? Are these parameters configurable via environment variables or the app.ini file?
31275 reputation · 13 Jan 2024, 00:27 UTC
When Forgejo starts and cannot reach its configured PostgreSQL database, it automatically retries the connection before giving up.
forgejo
postgresql3 (hard‑coded default).5 seconds.[ERROR] Failed to initialize database and exits with a non‑zero status.The retry loop reads two configuration values at startup; if they are present they override the defaults. These values can be set either as environment variables or in app.ini under the [database] section.
GITEA__DATABASE__RETRY_TIMES – integer number of attempts.GITEA__DATABASE__RETRY_INTERVAL – interval in seconds.app.ini:
[database] max_retry_times = 5 retry_interval = 2
GITEA__DATABASE__RETRY_TIMES=4 and GITEA__DATABASE__RETRY_INTERVAL=3, restart, and confirm four attempts with ~3 s gaps.Use comments to ask for clarification. Post a solution as an answer.
3,940 reputation · 13 Jan 2024, 03:26 UTC
While the previous response suggests internal retry parameters, it is important to clarify that Forgejo (inheriting Gitea's core logic) typically performs a single-shot connection attempt during the xorm.NewEngine initialization. If this initial handshake fails, the process generally exits with a non-zero status immediately.
For production deployments, especially in Kubernetes or Docker Compose, resilience is usually achieved through external orchestration rather than internal application settings:
Restart=on-failure in systemd or the restartPolicy in Kubernetes to cycle the pod until the database is ready.wait-for-it.sh or pg_isready script in the container entrypoint to block the Forgejo binary from starting until the PostgreSQL port is open.To verify this in your specific version, run Forgejo with FORGEJO_LOG_LEVEL=debug; a single error followed by an immediate process exit confirms the need for an external restart mechanism.