Gitea init-container "configure-gitea" failure #712

Closed
opened 2024-10-01 19:56:30 +00:00 by HanBrol0 · 2 comments
HanBrol0 commented 2024-10-01 19:56:30 +00:00 (Migrated from gitea.com)

Hello,

First off, I did not find any rules/guidelines for specific information required for creating an issue. I will try to provide as much detail as possible.

I've been trying to deploy Gitea through Helm. I've reduced the deployment complexity to only a single postgres instance in the configuration.

The Postgres deploys successfully, however the Gitea pod fails to initialize with 'configure-gitea' container. Attaching to the container long enough shows a failure message of before the container restarts:

2024/10/01 19:37:26 cmd/migrate.go:40:runMigrate() [F] Failed to initialize ORM engine: dial tcp 104.21.13.77:5432: connect: connection timed out

The IP it is trying to connect to is unrecognized. I have attached an ephemeral debug container to try the following:

  • Can the Container resolve the Postgresql Kubernetes Service object?
    Yes, the container can resolve postresql.gitea.svc.cluster.local to the appropriate IP address in the cluster

  • Can the Container resolve the address in the error message?
    No, again, this address is not recognized and there is nothing in my local DNS to point to this address

  • Ran "netstat -alt" to check the status of the connection to Postgres
    Active Internet connections (servers and established)
    Proto Recv-Q Send-Q Local Address Foreign Address State
    tcp 0 1 gitea-699557b479-bp6pw:49804 104.21.13.77:5432 SYN_SENT

So it seems like the init-container is trying to connect to some unidentifiable address for the Postgres connection. The cluster IP address for the Postgresql Service is 10.152.183.131 and the Pod's IP Address is 10.1.35.152.

I recompiled Gitea and the Docker image to my local repo in order to try to debug Gitea, however, Go is not really a programming language I am familiar with and was limited to basic print commands.

Are there debug options, and if not, could someone provide me with possible instructions on viewing the contents of the Postgres connection when runMigrate() is performed?

Edit: Adding logs of the 'configure-gitea' init container before failure:

==== BEGIN GITEA CONFIGURATION ====
2024/10/01 20:03:57 cmd/migrate.go:33:runMigrate() [I] AppPath: /usr/local/bin/gitea
2024/10/01 20:03:57 cmd/migrate.go:34:runMigrate() [I] AppWorkPath: /data
2024/10/01 20:03:57 cmd/migrate.go:35:runMigrate() [I] Custom path: /data/gitea
2024/10/01 20:03:57 cmd/migrate.go:36:runMigrate() [I] Log path: /data/log
2024/10/01 20:03:57 cmd/migrate.go:37:runMigrate() [I] Configuration file: /data/gitea/conf/app.ini
2024/10/01 20:03:57 ...2@v2.27.2/command.go:269:Run() [I] PING DATABASE postgres

Hello, First off, I did not find any rules/guidelines for specific information required for creating an issue. I will try to provide as much detail as possible. I've been trying to deploy Gitea through Helm. I've reduced the deployment complexity to only a single postgres instance in the configuration. The Postgres deploys successfully, however the Gitea pod fails to initialize with 'configure-gitea' container. Attaching to the container long enough shows a failure message of before the container restarts: 2024/10/01 19:37:26 cmd/migrate.go:40:runMigrate() [F] Failed to initialize ORM engine: dial tcp 104.21.13.77:5432: connect: connection timed out The IP it is trying to connect to is unrecognized. I have attached an ephemeral debug container to try the following: - Can the Container resolve the Postgresql Kubernetes Service object? Yes, the container can resolve postresql.gitea.svc.cluster.local to the appropriate IP address in the cluster - Can the Container resolve the address in the error message? No, again, this address is not recognized and there is nothing in my local DNS to point to this address - Ran "netstat -alt" to check the status of the connection to Postgres Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 1 gitea-699557b479-bp6pw:49804 104.21.13.77:5432 SYN_SENT So it seems like the init-container is trying to connect to some unidentifiable address for the Postgres connection. The cluster IP address for the Postgresql Service is 10.152.183.131 and the Pod's IP Address is 10.1.35.152. I recompiled Gitea and the Docker image to my local repo in order to try to debug Gitea, however, Go is not really a programming language I am familiar with and was limited to basic print commands. Are there debug options, and if not, could someone provide me with possible instructions on viewing the contents of the Postgres connection when runMigrate() is performed? Edit: Adding logs of the 'configure-gitea' init container before failure: ==== BEGIN GITEA CONFIGURATION ==== 2024/10/01 20:03:57 cmd/migrate.go:33:runMigrate() [I] AppPath: /usr/local/bin/gitea 2024/10/01 20:03:57 cmd/migrate.go:34:runMigrate() [I] AppWorkPath: /data 2024/10/01 20:03:57 cmd/migrate.go:35:runMigrate() [I] Custom path: /data/gitea 2024/10/01 20:03:57 cmd/migrate.go:36:runMigrate() [I] Log path: /data/log 2024/10/01 20:03:57 cmd/migrate.go:37:runMigrate() [I] Configuration file: /data/gitea/conf/app.ini 2024/10/01 20:03:57 ...2@v2.27.2/command.go:269:Run() [I] PING DATABASE postgres
justusbunsi commented 2024-10-18 13:32:14 +00:00 (Migrated from gitea.com)

@HanBrol0 Have you identified an issue on your side?

@HanBrol0 Have you identified an issue on your side?
HanBrol0 commented 2024-10-18 14:09:23 +00:00 (Migrated from gitea.com)

Yes, I apologize. I initially closed the issue because I found out there were forums to utilize, and this wasn't the appropriate place to post this. I then found the issue which was related to a faulty host configuration.

Yes, I apologize. I initially closed the issue because I found out there were forums to utilize, and this wasn't the appropriate place to post this. I then found the issue which was related to a faulty host configuration.
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#712
No description provided.