gogs
Docker Swarm (Dockerfile): Non-standard port healthcheck makes application unbootable
Gogs version
0.12.4+
Git version
- Server: 2.38.4
- Client: 2.17.1
Operating system
OS as defined in Dockerfile
Database
PostgreSQL 12
Describe the bug
I've ran my Gogs instance on v.0.12.3 for years since upgrading to newer versions didn't work either. When upgrading, it was impossible to connect from somewhere else and the application would die every few minutes. There would be very non-descript logs like:
2023-07-25T17:58:09.164396181Z 2023/07/25 17:58:09 [ INFO] Gogs 0.13.0
2023-07-25T17:54:51.934048099Z Jul 25 17:54:51 syslogd started: BusyBox v1.35.0
2023-07-25T17:58:09.164405316Z 2023/07/25 17:58:09 [TRACE] Work directory: /app/gogs
2023-07-25T17:54:51.977543890Z 2023/07/25 17:54:51 [TRACE] Log mode: File (Info)
2023-07-25T17:58:09.164413369Z 2023/07/25 17:58:09 [TRACE] Custom path: /data/gogs
2023-07-25T17:54:53.016295780Z Jul 25 17:54:53 sshd[26]: Server listening on :: port 22.
2023-07-25T17:54:53.016348375Z Jul 25 17:54:53 sshd[26]: Server listening on 0.0.0.0 port 22.
2023-07-25T17:58:09.164421000Z 2023/07/25 17:58:09 [TRACE] Custom config: /data/gogs/conf/app.ini
2023-07-25T17:58:09.164427876Z 2023/07/25 17:58:09 [TRACE] Log path: /data/gogs/log
2023-07-25T17:58:09.164432466Z 2023/07/25 17:58:09 [TRACE] Build time: 2023-02-25 01:42:03 UTC
2023-07-25T17:56:09.663411883Z Jul 25 17:56:09 syslogd exiting
After a lot of debugging I narrowed down the issue to the app.ini and later to any port other than 3000 not working. Turns out that the Docker healthcheck fails because it's hardcoded expecting the port to be 3000. It will not respond and inevitably turn the container unhealthy.
So --no-healthcheck works as a workaround when creating the service.
To reproduce
- Create a Docker swarm
- Create a Gogs service of v0.12.4+
- Configure a port other than 3000 in gogs.ini
The service will now perpetually restart and be unreachable from the outside.
Expected behavior
Configuring a non-3000 port in the app.ini should result in a healthy container.
Additional context
No response
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
@Vaults take a look at this PR: #7532 and the related issue. IMHO this should solve your problem. Would be interesting to know if my assumption that not using a proxy will resolve localhost directly on the machine.
@MatthiasJobst Thanks for helping out :) but I'm fine right now with just skipping the health checks. This would probably not change the problems with a non-standard port being used since the 3000 healthcheck is hardcoded within the container.
Skipping the healthcheck is an option, alternatively you could change the port in the Dockerfile as well. This would allow to use the healthcheck as well.