-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HOST setting in app.ini incorrectly used. #24552
Comments
Hi @lelanthran , |
Is this resolved? |
Sorry about taking so long to reply; I haven't tried the suggestion from @DanieleAurilio, I will try it and report back tomorrow. My feeling is that, even if that works, that is different to what the documentation says should happen. If it works, maybe a new issue to change the documentation to match the behaviour? |
Hello all, @DanieleAurilio, @lunny The suggestion from @DanieleAurilio to use Warm Regards (Also, thanks @DanieleAurilio and @lunny for taking the time to respond) |
Hello
What do you maintainers think about this? |
This patchset changes the connection string builder to use net.URL and the host/port parser to use the stdlib function for splitting host from port. It also adds a footnote about a potentially required portnumber for postgres UNIX sockets. Fixes: #24552
This patchset changes the connection string builder to use net.URL and the host/port parser to use the stdlib function for splitting host from port. It also adds a footnote about a potentially required portnumber for postgres UNIX sockets. Fixes: go-gitea#24552
Backport #27723 by @mpldr This patchset changes the connection string builder to use net.URL and the host/port parser to use the stdlib function for splitting host from port. It also adds a footnote about a potentially required portnumber for postgres UNIX sockets. Fixes: #24552 Co-authored-by: Moritz Poldrack <[email protected]>
This patchset changes the connection string builder to use net.URL and the host/port parser to use the stdlib function for splitting host from port. It also adds a footnote about a potentially required portnumber for postgres UNIX sockets. Fixes: go-gitea#24552
This patchset changes the connection string builder to use net.URL and the host/port parser to use the stdlib function for splitting host from port. It also adds a footnote about a potentially required portnumber for postgres UNIX sockets. Fixes: go-gitea#24552
Description
My app.ini file has the following line:
HOST = /var/run/postgresql/.s.PGSQL.27541
Gitea logs the following messages to syslog:
May 5 20:36:53 small-repo gitea[37607]: 2023/05/05 20:36:53 routers/common/db.go:34:InitDBEngine() [E] ORM engine initialization attempt #1/10 failed. Error: dial unix /var/run/postgresql/.s.PGSQL.27541/.s.PGSQL.5432: connect: not a directory
The documentation (over here) says:
HOST: 127.0.0.1:3306: Database host address and port or absolute path for unix socket [mysql, postgres] (ex: /var/run/mysqld/mysqld.sock).
When I change the app.ini to have only the directory name, it doesn't find the file
.s.PGSQL.27541
(because postgresql creates the socket file based on the port that it is listening on, which in my installation is not the standard port).HOST = /var/run/postgresql
Now the logs say:
May 5 20:44:51 small-repo gitea[38047]: 2023/05/05 20:44:51 routers/common/db.go:34:InitDBEngine() [E] ORM engine initialization attempt #1/10 failed. Error: dial unix /var/run/postgresql/.s.PGSQL.5432: connect: no such file or directory
As a temporary fix I have soft-linked the expected filename (
.s.PGSQL.5432
) to the actual file (.s.PGSQL.27541
), and it works as expected when the file.s.PGSQL.5432
is soft-linked to the file created by postgresql.The expected behaviour is what the documentation says, that the HOST value is used as-is, and gitea does not append the hardcoded
.s.PGSQL.5432
to it.The hardcoded value appears to be returned by
parsePostgreSQLHostPort()
in theport
variable. Thepq
library functionopen()
receives a string, and builds the final string by appending.s.PGSQL.<port>
, which results in the incorrect filename being used.Gitea Version
1.19.3
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
n/a
Screenshots
n/a
Git Version
n/a
Operating System
Bullseye
How are you running Gitea?
Bullseye repo.
Database
PostgreSQL
The text was updated successfully, but these errors were encountered: