Gitea: Crashes after Gitea is configured - "Unable to initialize Bleve Issue Indexer"

Created on 20 Apr 2020  Â·  18Comments  Â·  Source: go-gitea/gitea

  • Gitea version (or commit ref): latest and 1.0
  • Git version: What ever is in the Docker image
  • Operating system: Debian Buster with Docker (version 19.03.8, build afacb8b7f0)
  • 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

Description

Using the instructions found on the website I've make a Mysql server in Docker and setup using the database preparation instructions. I could guarantee that the Docker Mysql server works because I could connect and control the server using Mysql Workbench. I could also attest that the creditial and permissions for the

I've tried many times with different settings. Also dumped the entire Database and persistant files of Gitea between test runs. I would repeat the same problematic result everytime.

I suspect it might have to do with the fact I am using Portainer (not sure what's the difference). Not sure...

Before, I've tried using Docker Compose I ran into another problem that is why I didn't use that.

To replicate my problem:

  • Make a Mysql DB, pretty much default. connect to same network
  • Gitea using settings below, go to gitea's webpage, go to login
  • Enter DB info and save
  • Saves the info, reloads and crashes. Crashes everytime afterwards as well.

Screenshots

Gitea Docker

Docker Settings
image

Docker logs, shows Gitea terminating for no reason... repeatedly.
image

Mysql Docker

image

image

reviewenot-a-bug

Most helpful comment

Ok it looks like for some reason bleve doesn't like that filesystem. I guess there's something odd about it - @lunny might know more. What's your host system?

In any case the workaround is to use the db issue indexer.

In app.ini:

[indexer]
ISSUE_INDEXER_TYPE = db

All 18 comments

is there anything in /dat/gitea/log? Can Gitea even write to /data/gitea/log?

Sorry, clicked the wrong button haha.

Anyways, should have included the log.

So, yes that path could be read. The log file is too big to post entirely but the last few lines mentioned what went wrong...

2020/04/18 22:06:39 routers/init.go:99:GlobalInit() [I] ORM engine initialization successful!
2020/04/18 22:06:39 ...orm/dialect_mysql.go:431:GetTables() [I] [SQL] SELECT TABLE_NAME, ENGINE, TABLE_ROWS, AUTO_INCREMENT, TABLE_COMMENT from INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA=? AND (ENGINE='MyISAM' OR ENGINE = 'InnoDB' OR ENGINE = 'TokuDB') [giteadb]
2020/04/18 22:06:39 ...orm/dialect_mysql.go:320:GetColumns() [I] [SQL] SELECT COLUMN_NAME, IS_NULLABLE, COLUMN_DEFAULT, COLUMN_TYPE, COLUMN_KEY, EXTRA,COLUMN_COMMENT FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = ? AND TABLE_NAME = ? [giteadb oauth2_session]
2020/04/18 22:06:39 ...orm/dialect_mysql.go:460:GetIndexes() [I] [SQL] SELECT INDEX_NAME, NON_UNIQUE, COLUMN_NAME FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = ? AND TABLE_NAME = ? [giteadb oauth2_session]
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT id, type, name, is_actived, is_sync_enabled, cfg, created_unix, updated_unix FROM login_source WHERE (is_actived = ? and type = ?) []interface {}{true, 6} - took: 409.114µs
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT repo.id FROM repository repo WHERE repo.num_watches!=(SELECT COUNT() FROM watch WHERE repo_id=repo.id AND mode<>2) - took: 325.528µs
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT repo.id FROM repository repo WHERE repo.num_stars!=(SELECT COUNT(
) FROM star WHERE repo_id=repo.id) - took: 189.775µs
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT label.id FROM label WHERE label.num_issues!=(SELECT COUNT() FROM issue_label WHERE label_id=label.id) - took: 276.516µs
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT user.id FROM user WHERE user.num_repos!=(SELECT COUNT(
) FROM repository WHERE owner_id=user.id) - took: 213.038µs
2020/04/18 22:06:39 .../xorm/session_raw.go:196:exec() [I] [SQL] DELETE FROM deleted_branch WHERE (deleted_unix < ?) []interface {}{1587175599} - took: 1.53767ms
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT issue.id FROM issue WHERE issue.num_comments!=(SELECT COUNT() FROM comment WHERE issue_id=issue.id AND type=0) - took: 447.585µs
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT id, owner_id, lower_name, name, description, website, original_service_type, original_url, default_branch, num_watches, num_stars, num_forks, num_issues, num_closed_issues, num_pulls, num_closed_pulls, num_milestones, num_closed_milestones, is_private, is_empty, is_archived, is_mirror, status, is_fork, fork_id, is_template, template_id, size, is_fsck_enabled, close_issues_via_commit_in_any_branch, topics, avatar, created_unix, updated_unix FROM repository WHERE (id > 0) - took: 1.24857ms
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT external_id, user_id, login_source_id, raw_data, provider, email, name, first_name, last_name, nick_name, description, avatar_url, location, access_token, access_token_secret, refresh_token, expires_at FROM external_login_user WHERE provider=? ORDER BY login_source_id ASC, external_id ASC LIMIT 100 []interface {}{"github"} - took: 1.264932ms
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT repo.id FROM repository repo WHERE repo.num_closed_issues!=(SELECT COUNT(
) FROM issue WHERE repo_id=repo.id AND is_closed=? AND is_pull=?) []interface {}{true, false} - took: 683.466µs
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT repo.id FROM repository repo WHERE repo.num_closed_pulls!=(SELECT COUNT() FROM issue WHERE repo_id=repo.id AND is_closed=? AND is_pull=?) []interface {}{true, true} - took: 508.8µs
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT repo.id FROM repository repo WHERE repo.num_forks!=(SELECT COUNT(
) FROM repository WHERE fork_id=repo.id) - took: 290.683µs
2020/04/18 22:06:39 ...er/issues/indexer.go:142:func2() [I] PID 15: Initializing Issue Indexer: bleve
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT pull_request.id FROM pull_request WHERE (status=?) []interface {}{1} - took: 521.433µs
2020/04/18 22:06:39 .../xorm/session_raw.go:78:queryRows() [I] [SQL] SELECT id, repo_id, hook_id, uuid, type, url, signature, payload_content, http_method, content_type, event_type, is_ssl, is_delivered, delivered, is_succeed, request_content, response_content FROM hook_task WHERE (is_delivered=?) []interface {}{false} - took: 499.954µs
2020/04/18 22:06:40 ...er/issues/indexer.go:150:func2() [F] Unable to initialize Bleve Issue Indexer: no such device

Well that's the hint. You need to set your indexer configuration correctly, in particular the ISSUE_INDEXER_PATH setting in [indexer]. See https://docs.gitea.io/en-us/config-cheat-sheet/#indexer-indexer

Hi @zeripath, I did some trial and error before resorting to here again.

I've tried a few other settings using the link you sent too. Still doesn't work... because of other problems (which I won't mentioned since it's prob the config)

So far, the Docker does NOT have any settings that were changed, so everything in [indexer] should be default.

As for the ISSUE_INDEXER_PATH setting, I couldn't find any other documentation or info on docs.gitea.io for what to set this to. The official documentation doesn't seem to talk about setting this particular setting.

So what exactly should I set for this anyways?

Could you paste your app.ini (suitably sanitized please.)

You would need to add a [indexer] section to your app.ini and within that [indexer] section set ISSUE_INDEXER_PATH to something appropriate.

However, it would be useful to work out what the default path is - as clearly this is not correct for the docker.

Also what version of Gitea are you using?

Hi @zeripath. I have used both version 1.0 and whatever is at "latest" before. Both have the same problem, errors and symptoms.

I've zipped app.ini as it is right now. Haven't changed anything included the pass which isn't salted... whatever.

I basically haven't changed anything different from whatever was in the Docker Documentation. Nothing really that would cause problems. Other than the fact that I am using regular Docker (in portainer) rather than Docker Compose. Shouldn't make a difference really.

As for the ISSUE_INDEXER_PATH setting, it is the default setting.

Mine:
image

Docs:
image

app.zip

Just checked the persistent data from the Docker.

/data which mounted to a host file

I found the issues.bleve which is a folder.

Just writing this just incase this is important

Btw, gitea runs as the user "tmod" fyi.

Permissions:
image

@Nathan13888 you've said:

I have used both version 1.0 and whatever is at "latest" before. Both have the same problem, errors and symptoms.

Gitea 1.0 is a _very_ old version, "and whatever is at latest" is not very descriptive. Please let us know your current version of Gitea, which you can obtain by running:

/path/to/gitea --version

from inside your docker instance.

@guillep2k Thanks for tuning in.

What I mean is that I tried both version 1.0 and the version using the tag "latest". I only tried 1.0 because "latest" wasn't working for me (never did, always crashed after setup).

Anyways, this is what I found: Gitea version 1.12.0+dev-201-g50475fff0 built with GNU Make 4.2.1, go1.14.2 : bindata, sqlite, sqlite_unlock_notify

use at least 1.11.x version ... migration from v1.0 has ben droped in v1.12!

and for the error: just try to delete the indexer files

Hey all, I've deleted everything again to start from scratch. I've recreated a new Docker container using the same 1.12 version of Gitea.

The settings are the same as the ones in my first post.

Upon creation, I open the install page and enter the database password and submit the info.

Right afterwards, when I reload my browser, the website is gone (after a crash). When starting the container again, it crashes. in the log file, the same issue is here.

Using @6543 's suggestion, I deleted the files in the /data/gitea/indexers/ folder. I start the Docker again, crashes as usual but the deleted files weren't recreated afterwards either. The log says the same error.

Here's the line that keeps coming back:

2020/04/22 17:13:32 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT `external_id`, `user_id`, `login_source_id`, `raw_data`, `provider`, `email`, `name`, `first_name`, `last_name`, `nick_name`, `description`, `avatar_url`, `location`, `access_token`, `access_token_secret`, `refresh_token`, `expires_at` FROM `external_login_user` WHERE provider=? ORDER BY login_source_id ASC, external_id ASC LIMIT 100 [gitlab] - 584.032µs
2020/04/22 17:13:32 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT repo.id FROM `repository` repo WHERE repo.num_closed_issues!=(SELECT COUNT(*) FROM `issue` WHERE repo_id=repo.id AND is_closed=? AND is_pull=?) [true false] - 590.735µs
2020/04/22 17:13:32 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT repo.id FROM `repository` repo WHERE repo.num_closed_pulls!=(SELECT COUNT(*) FROM `issue` WHERE repo_id=repo.id AND is_closed=? AND is_pull=?) [true true] - 510.004µs
2020/04/22 17:13:32 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT repo.id FROM `repository` repo WHERE repo.num_forks!=(SELECT COUNT(*) FROM `repository` WHERE fork_id=repo.id) [] - 487.552µs
2020/04/22 17:13:32 ...er/issues/indexer.go:142:func2() [I] PID 15: Initializing Issue Indexer: bleve
2020/04/22 17:13:32 ...er/issues/indexer.go:158:func2() [F] Unable to initialize Bleve Issue Indexer: no such device
***

Ok it looks like for some reason bleve doesn't like that filesystem. I guess there's something odd about it - @lunny might know more. What's your host system?

In any case the workaround is to use the db issue indexer.

In app.ini:

[indexer]
ISSUE_INDEXER_TYPE = db

I see. Interesting observation. The server I'm running this on is my home server that also contains my NAS (which is really built out of consumer parts).

The volume the Gitea Docker runs off is this encrypted drive pool.

The pool consists of some WD Red drives pooled together using MergerFS. The base FS of the drives is XFS with Luks. I'll try changing this setting and report my results.

Okay, what a success! This one-liner fixed everything! It doesn't crash now. Awesome.

Btw, adding onto my last message, the server (running Docker) runs on Debian Buster.

Thanks @zeripath and all the others for all your help all along.

Changed the title so it is easier for others to find it.

This should really go in the Installation with Docker page as I had the exact same problem. It seems like the default setup of gitea doesn't work well with the fairly common use of MergerFS.

Linuxserver.io The Perfect Media Server - 2019 Edition
Serverbuilds.net Setting up media server using Ubuntu and SnapRaid

Symptoms

Using the exact Installation with Docker steps, the docker instance crashes without details at the end of setup yeilding Received signal 15; terminating.

Steps to diagnose and resolve

  1. Edit /gitea-data/gitea/conf/app.ini as follow
 [log]
 ROOT_PATH = /data/gitea/log
 MODE      = console
 LEVEL     = debug
 XORM     = console
  1. Find that the real error is [F] Unable to initialize Bleve Issue Indexer at path: /data/gitea/indexers/issues.bleve Error: no such device
  2. Search and find this issue
  3. Edit /gitea-data/gitea/conf/app.ini as follow
 [indexer]
 ISSUE_INDEXER_PATH = /data/gitea/indexers/issues.bleve
 ISSUE_INDEXER_TYPE = db

Thank you very much @jshank ! I don't know why I thought because I had Docker running on Windows Server 2019 I couldn't use Gitea. But with your modification it's working!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mirhec picture mirhec  Â·  3Comments

tuxfanou picture tuxfanou  Â·  3Comments

kolargol picture kolargol  Â·  3Comments

internalfx picture internalfx  Â·  3Comments

jonasfranz picture jonasfranz  Â·  3Comments