gitea: Error 502 after version upgrade

Gitea version (or commit ref): Gitea version 1.9.2
Git version: git version 2.17.1
Operating system: Ubuntu 18.04.3
Database (use [x]):
- PostgreSQL
- [x ] MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- [x ] Not relevant
Log gist:

Description

I tried to upgrade from version 1.8.3 to 1.9.2. I downloaded it(https://dl.gitea.io/gitea/1.9.2/gitea-1.9.2-linux-amd64) and replaced binary in global location: sudo cp gitea /usr/local/bin/gitea Gitea is in running status, but got error 502 Bad Gateway nginx/1.14.0 (Ubuntu) when tried to reach it.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 23 (8 by maintainers)

Most upvoted comments

I am not the most expert on the code indexer part but from what I know, it was present at least in 1.8.0 but it needed futher rework later and was limited. The problem come from that the schema of data was changed in between 1.8.0 and 1.9.0. The indexer needed a full rebuild of the index at each schema change. This may take time and ressource and can be problematic on some limited platform. After the complete rebuild of the index it should be good to run even on limited platform.

For details, a PR exist to be able to not rebuild the index at migration but manually next time #7753

@sapk Yes, that’s correct. And it will happen again when upgrading to 1.10.0. I think we should include some kind of warning in the upgrade guide?

guillep2k on Sep 5, 2019

I am not the most expert on the code indexer part but from what I know, it was present at least in 1.8.0 but it needed futher rework later and was limited. The problem come from that the schema of data was changed in between 1.8.0 and 1.9.0. The indexer needed a full rebuild of the index at each schema change. This may take time and ressource and can be problematic on some limited platform. After the complete rebuild of the index it should be good to run even on limited platform.

For details, a PR exist to be able to not rebuild the index at migration but manually next time #7753

sapk on Sep 5, 2019

Thanks for the explanation, but what is current solution for this?

Just upgrade Gitea in a slow part of the day; perhaps blocking accesses, and leave it there rebuilding the index (the log should calm down after finishing). It shouldn’t take too much time. In our medium sized VM (server at least 8 years old), it took around 5~10 seconds for every 100 MB of repo.

Alternatively, you could disable repository indexing while upgrading:

[indexer]
REPO_INDEXER_ENABLED = false

And remove the directory pointed to by REPO_INDEXER_PATH along with its contents. When you restart your instance there should not be any performance penalty associated with the repository indexing (of course, there will be no repository indexes either). Then you can choose the right moment to enable them again.

guillep2k on Sep 9, 2019

I cann’t say exactly but gitea can provide pprof cpu and mem profile. You could used that options to find what take cpu times. Thoses options are not well documented #6240 but you can found all the information from #4560. After the profile file are generated you can use standard go tool pprof to read them.

sapk on Sep 5, 2019