Nothing happens when using the initial configuration page

[KuenzelIT]

Description

After clicking on "Install Gitea" in the initial configuration the page is loading for a few seconds and then nothing happens and the initial configuration page is still shown, even after visiting the gitea url again. I did not change any options.

Gitea Version

1.19.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/KuenzelIT/20f406fc2edf5378d1d1dd4ad9e88cbc

Screenshots

No response

Git Version

No response

Operating System

Synology DSM

How are you running Gitea?

Docker Compose on a Synology:

version: "3"

networks: gitea: external: false

services: server: image: gitea/gitea:1.19.0 container_name: gitea environment:

• USER_UID=1026
• USER_GID=100
• GITEAdatabaseDB_TYPE=mysql
• GITEAdatabaseHOST=db:3306
• GITEAdatabaseNAME=gitea
• GITEAdatabaseUSER=gitea
• GITEAdatabasePASSWD=gitea restart: always networks:
• gitea volumes:
• ./gitea:/data
• /etc/TZ:/etc/timezone:ro
• /etc/localtime:/etc/localtime:ro ports:
• "3000:3000"
• "222:22" depends_on:

• db

  db: image: mysql:8 restart: always environment:

• MYSQL_ROOT_PASSWORD=gitea
• MYSQL_USER=gitea
• MYSQL_PASSWORD=gitea
• MYSQL_DATABASE=gitea networks:
• gitea volumes:
• ./mysql:/var/lib/mysql

Database

MySQL

[wxiaoguang]

I have tested your docker-compose.yaml :

1. Copy it into my docker-compose.yaml
2. docker-compose up
3. Visit localhost:3000
4. Click Install

After a few seconds, I can see the login UI.

The log looks like this:

gitea          | 2023/04/08 18:15:21 ...c/net/http/server.go:2122:ServeHTTP() [I] [64313eb9] PING DATABASE mysql
gitea          | 2023/04/08 18:15:24 ...eb/routing/logger.go:67:func1() [W] [64313eab-5] router: slow      POST / for 172.28.0.1:55794, elapsed 3456.8ms @ install/install.go:236(install.SubmitInstall)
gitea          | 2023/04/08 18:15:31 ...s/install/install.go:515:SubmitInstall() [I] Save settings to custom config file /data/gitea/conf/app.ini
gitea          | 2023/04/08 18:15:31 routers/common/db.go:21:InitDBEngine() [I] Beginning ORM engine initialization.
gitea          | 2023/04/08 18:15:31 routers/common/db.go:28:InitDBEngine() [I] ORM engine initialization attempt #1/10...

From your log , I can see:

######### the first try

gitea     | 2023/04/07 18:39:39 ...c/net/http/server.go:2122:ServeHTTP() [I] [6430474b] PING DATABASE mysql
gitea     | 2023/04/07 18:39:43 ...eb/routing/logger.go:67:func1() [W] [64304622] router: slow      POST / for 192.168.16.1:54058, elapsed 3746.2ms @ install/install.go:236(install.SubmitInstall)
======= why there is no detailed log here
gitea     | 2023/04/07 18:39:55 ...eb/routing/logger.go:98:func1() [I] router: completed POST / for 192.168.16.1:54058, 200 OK in 16550.8ms @ install/install.go:236(install.SubmitInstall)
gitea     | 2023/04/07 18:45:41 ...eb/routing/logger.go:98:func1() [I] [643048b5] router: completed GET / for 192.168.16.1:54402, 200 OK in 93.3ms @ install/install.go:90(install.Install)

...

######### the second try , the database part has been installed, but the app.ini doesn't get INSTALL_LOCK=true

gitea     | 2023/04/07 18:47:15 ...s/install/install.go:229:checkDatabase() [I] [64304913] Gitea will be installed in a database with: hasPostInstallationUser=false, dbMigrationVersion=244
gitea     | 2023/04/07 18:47:15 ...c/net/http/server.go:2122:ServeHTTP() [I] [64304913] PING DATABASE mysql
gitea     | 2023/04/07 18:47:16 modules/web/wrap.go:40:func1() [W] [64304913] Table system_setting Column version db default is , struct default is 1
gitea     | 2023/04/07 18:47:19 ...eb/routing/logger.go:67:func1() [W] [64304622] router: slow      POST / for 192.168.16.1:54402, elapsed 3413.2ms @ install/install.go:236(install.SubmitInstall)
======= why there is no detailed log here
gitea     | 2023/04/07 18:47:34 ...eb/routing/logger.go:98:func1() [I] [64304913] router: completed POST / for 192.168.16.1:54402, 200 OK in 18438.7ms @ install/install.go:236(install.SubmitInstall)

Just FYI, I have no more idea about this issue at the moment.

[wxiaoguang]

Does your cookie/domain/browser work correctly? (Just a guess, I am not sure)

Maybe there is an error message, but the wrong cookie setting may cause the error message wouldn't be displayed, so you didn't get the error feedback?

[KuenzelIT]

Thank you for testing!

Your logs gave me the idea to see if the app.ini was created and it was. I then tried settting the DOMAIN and SSH_DOMAIN from localhost to my servers domain name and see if anything changes. But the result was the same.

I also tried with INSTALL_LOCK = true to see any changes and the ORM tried to initialize, but after waiting for the mysql server, it didn't try again, although there were some attempts left.

I also tried with a fresh browser. The behaviour was the same.

As the logs say, the installer is very slow. Takes my machine more than 60 seconds to finish the POST request. May be my machine, but seems a little odd (in your case 10 seconds).

I have no idea what else to try right now. :)

[wxiaoguang]

As the logs say, the installer is very slow. Takes my machine more than 60 seconds to finish the POST request. May be my machine, but seems a little odd (in your case 10 seconds).

Hmm ... no idea either. Could the "slow" be the problem? What's your environment (hardware) & limitation? Is there enough CPU and memory resrouce?

[KuenzelIT]

I'm using a Synology DS920+. The performance is ok and I'm running some other docker containers without a problem. I thought Gitea is lightweight and should work. :)

I will monitor the CPU and memory the next time I try the install. But since the logs say that the POST request completed, I assume that this is not the problem.

Thanks again for your help!

[lunny]

Looks like it's normal from the provided logs.

[nbgibson]

@KuenzelIT Out of curiosity, are you running the docker container on a volume that is using btrfs? I'm encountering something similar in my install as well. However, I'm using a dedicated MariaDB instance running on the Syn box by way of their package center. The install is progressing as I can see it periodically making new tables in my DB, but it is taking its sweet time. I did a bit of digging around and it seems that btrfs and the data checksum checking of files in those shares may be the root of the problem here.

See:

• https://www.reddit.com/r/synology/comments/s9f3cg/mariadb_on_btrfs_is_slow_best_options/
• https://www.reddit.com/r/synology/comments/ry6nrk/til_dont_put_your_docker_confs_into_the_default/

I have yet to find the referenced Synology documentation on the matter* but I could see where the checksum checking could play a great deal into the performance overhead we're seeing here. I'm going to let things churn overnight on my end and try and set aside some time to see if the issue comes up on a MariaDB instance running on a different host.

• It can be found here

To ensure service quality, we recommend not enabling data checksum when the shared folder will be used for the following services: Hosting databases or virtual machines Storing video recordings of Surveillance Station Running services that require a small and random write pattern

[KuenzelIT]

Thanks for the idea. Unfortunately I'm not using btrfs. I also haven't tried to install gitea in a while, maybe I'll try again in a few days.

[thannerfabian]

@KuenzelIT I am currently facing the same issues on a Synology DS224+. I am also running other docker containers without any problems. RAM and CPU load are both under 10% and I am not using btrfs as well.

The difference in my environment is, that I use an already installed MySQL instance and no docker container for it. And I use the latest version of gitea not 1.19.0 (didn´t check if the latest is 1.19.0).

Did you find any solution?

[KuenzelIT]

I did not find a solution and dropped trying it for now, sorry :(

[thannerfabian]

I am not sure how I got it working, but I did the installation on my Mac. After loading for a few minutes, I tried to open the webpage on one of my servers. In this moment, the installation was done and I got forwarded to homepage of Gitea. I dn´t know if it was luck or if this is the solution.

[lovehumans]

I'm having the same problem, no btrfs, DS720+, using forgejo:9-rootless with a pg:14 in a container. I don't see any CPU usage from the forgejo container and it just doesn't do anything after clicking "Install". I don't see it writing an ini file in the volume either. Other docker projects run fine.

[lunny]

Maybe you need to check whether there is permission to write the app.ini to the mounted data directory.

[lovehumans]

That was a hurdle I've crossed since posting, but it's still not working. I had to chown the folders to user id 1000, because that's the ID of the GIT user inside the docker container, regardless of what I set the environment variables for USER_ID, within the docker compose yaml.

Now after doing this, if I select SQLite3, it does create an app.ini, but when I pick the Postgres DB, it does not. (When picking SQLite3, the install doesn't work, since the DB Type is set to Postgres in the yaml, but that's beside the point, I'd prefer a Postgres install anyway)

[lovehumans]

I gave up on Postgres DB and have it running on SQLite now. So a major hint for anyone having issues: even though the error messages might not suggest something is up with the DB, it might be.