Long delay on startup

[beppler]

• Gitea version (or commit ref): 1.8.3
• Git version: 2.20.1
• Operating system: Debian 10
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist: https://gist.github.com/beppler/ef6e4dcc2ec2b88aa6d036d4037fc6ad

Description

When starting gitea there are a long delay (apox 3 minutes) between the first logs and start listening requests.

This is not the same of #5953 because it happens always, not only when Gitea is upgraded.

[lunny]

Could you change the log level to trace and enable xorm log?

[zeripath]

Do you have repository indexing on?

[beppler]

Yes, I have repository indexing and it is using bleve.

[indexer]
ISSUE_INDEXER_PATH   = /var/opt/gitea/data/indexers/issues.bleve
REPO_INDEXER_ENABLED = true
REPO_INDEXER_PATH    = /var/opt/gitea/data/indexers/repos.bleve

[beppler]

Also, xorm.log for the period is on https://gist.github.com/beppler/e55dfbab135170eaa505395137697a88

[zeripath]

I bet the delay is bleve starting.

[lunny]

bleve should start asynchronously. see

gitea/routers/init.go

Line 97 in 8ec6597

if err := issue_indexer.InitIssueIndexer(false); err != nil {

, the parameter is false.

[zeripath]

In my work on making Gitea respond to sign-up gracefully - these certainly seem to cause Gitea to lock and I've had to wrap the initialisation in a goroutine.

[beppler]

I changed the log level to Trace, here is the log generated during startup.

[zeripath]

@beppler it's the repo indexer.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[lunny]

2019/07/29 14:48:12 [T] Doing: DeletedBranchesCleanup
2019/07/29 14:50:55 [I] SQLite3 Supported

It's not indexer, it's cron taskes. Some taskes could be configed run at start but not on new go rountines.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.