github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-13 02:57:44 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Failed to initialize issue indexer: invalid argument -- will not install #4137

New Issue
Closed
opened 2025-11-02 05:39:54 -06:00 by GiteaMirror · 20 comments
GiteaMirror commented 2025-11-02 05:39:54 -06:00
Owner
Copy Link

Originally created by @brandonkal on GitHub (Oct 17, 2019).

  • Gitea version (or commit ref): gitea/gitea:1.9.4-linux-amd64 (also an issue on gitea:latest)
  • Git version: 2.17.1
  • Operating system: Kubernetes
  • 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/brandonkal/299fa99968e5939633c825045a33cffe

Description

This error occurs when the PV is on a specific mounted drive that is a folder shared with the Kubernetes host (Ubuntu 18.04 KVM with microk8s). The logged error is not descriptive enough to conclude it is a permissions issue. From the host, it is clear the files are created in the mounted location without issue.

Originally created by @brandonkal on GitHub (Oct 17, 2019). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - Gitea version (or commit ref): gitea/gitea:1.9.4-linux-amd64 (also an issue on gitea:latest) - Git version: 2.17.1 - Operating system: Kubernetes - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: https://gist.github.com/brandonkal/299fa99968e5939633c825045a33cffe ## Description This error occurs when the PV is on a specific mounted drive that is a folder shared with the Kubernetes host (Ubuntu 18.04 KVM with microk8s). The logged error is not descriptive enough to conclude it is a permissions issue. From the host, it is clear the files are created in the mounted location without issue.
GiteaMirror added the type/questionissue/confirmed labels 2025-11-02 05:39:54 -06:00
GiteaMirror commented 2025-11-02 05:39:55 -06:00
Author
Owner
Copy Link

@guillep2k commented on GitHub (Oct 22, 2019):

Could you please post your [indexer] configuration?

@guillep2k commented on GitHub (Oct 22, 2019): Could you please post your `[indexer]` configuration?
GiteaMirror commented 2025-11-02 05:39:55 -06:00
Author
Owner
Copy Link

@guillep2k commented on GitHub (Nov 13, 2019):

@brandonkal One user at Discord had the same problem. It turned out that Gitea was running in a virtual box shared folder; running Gitea on a non-shared folder solved his issue. Please check if anything similar might be happening to you.

@guillep2k commented on GitHub (Nov 13, 2019): @brandonkal One user at Discord had the same problem. It turned out that Gitea was running in a virtual box shared folder; running Gitea on a non-shared folder solved his issue. Please check if anything similar might be happening to you.
GiteaMirror commented 2025-11-02 05:39:56 -06:00
Author
Owner
Copy Link

@brandonkal commented on GitHub (Nov 13, 2019):

It's just vanilla microk8s on Ubuntu 18.04 with Racher's local path provisioner.

As stated, the bug here is that the error is not descriptive of whatever disk IO issue Gitea is having.

It was an NFS or SMB mounted volume backing the PV. I know vagrant/virtual box uses network shares for shared volumes. So it could be a similar Gitea bug.

@brandonkal commented on GitHub (Nov 13, 2019): It's just vanilla microk8s on Ubuntu 18.04 with Racher's local path provisioner. As stated, the bug here is that the error is not descriptive of whatever disk IO issue Gitea is having. It was an NFS or SMB mounted volume backing the PV. I know vagrant/virtual box uses network shares for shared volumes. So it could be a similar Gitea bug.
GiteaMirror commented 2025-11-02 05:39:56 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 13, 2019):

Please notice, indxer folder cannot be shared by multiple gitea instance.

@lunny commented on GitHub (Nov 13, 2019): Please notice, indxer folder cannot be shared by multiple gitea instance.
GiteaMirror commented 2025-11-02 05:39:56 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Nov 13, 2019):

So @brandonkal the invalid argument is the error that comes out of bleve - it doesn't appear to tell us anything more than that.

I agree it is opaque to the extreme but unless anyone can find a way of getting bleve to tell us what the problem is, that's what we're stuck with.

@zeripath commented on GitHub (Nov 13, 2019): So @brandonkal the invalid argument is the error that comes out of bleve - it doesn't appear to tell us anything more than that. I agree it is opaque to the extreme but unless anyone can find a way of getting bleve to tell us what the problem is, that's what we're stuck with.
GiteaMirror commented 2025-11-02 05:39:57 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jan 12, 2020):

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.

@stale[bot] commented on GitHub (Jan 12, 2020): 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.
GiteaMirror commented 2025-11-02 05:39:57 -06:00
Author
Owner
Copy Link

@brandonkal commented on GitHub (Jan 12, 2020):

See you next month bot. #notstale

@brandonkal commented on GitHub (Jan 12, 2020): See you next month bot. #notstale
GiteaMirror commented 2025-11-02 05:39:57 -06:00
Author
Owner
Copy Link

@MattDahEpic commented on GitHub (Feb 24, 2020):

This also occurs when the work directory is on a 9p virtio mount.

@MattDahEpic commented on GitHub (Feb 24, 2020): This also occurs when the work directory is on a 9p virtio mount.
GiteaMirror commented 2025-11-02 05:39:57 -06:00
Author
Owner
Copy Link

@Kramins commented on GitHub (Dec 16, 2020):

I am also having this problem on microk8s and my data volume is on a 9p virtio mount as @MattDahEpic mentioned.

Are there any known workarounds that would allow me to keep my data volume mounted over 9p?

Edit:
After a little research, turns out I can change the indexer type to Database
ISSUE_INDEXER_TYPE = db

@Kramins commented on GitHub (Dec 16, 2020): I am also having this problem on microk8s and my data volume is on a 9p virtio mount as @MattDahEpic mentioned. Are there any known workarounds that would allow me to keep my data volume mounted over 9p? Edit: After a little research, turns out I can change the indexer type to Database ISSUE_INDEXER_TYPE = db
GiteaMirror commented 2025-11-02 05:39:57 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 17, 2020):

For most Gitea instances, db is enough.

@lunny commented on GitHub (Dec 17, 2020): For most Gitea instances, `db` is enough.
GiteaMirror commented 2025-11-02 05:39:58 -06:00
Author
Owner
Copy Link

@aaronjwood commented on GitHub (Jan 2, 2021):

I second this issue when using a 9p mount via kvm/qemu. Changing the indexer type to db fixes it. I don't have much context on Bleve indexer, does anyone know why it would break under a specific mount type? I've had Gitea working with NFS before, I figured things would have broken there first...

@aaronjwood commented on GitHub (Jan 2, 2021): I second this issue when using a 9p mount via kvm/qemu. Changing the indexer type to `db` fixes it. I don't have much context on Bleve indexer, does anyone know why it would break under a specific mount type? I've had Gitea working with NFS before, I figured things would have broken there first...
GiteaMirror commented 2025-11-02 05:39:58 -06:00
Author
Owner
Copy Link

@aaronjwood commented on GitHub (Jan 2, 2021):

I'm guessing this has something to do with mmap being used and it not working across the boundary of a hypervisor...?

@aaronjwood commented on GitHub (Jan 2, 2021): I'm guessing this has something to do with mmap being used and it not working across the boundary of a hypervisor...?
GiteaMirror commented 2025-11-02 05:39:58 -06:00
Author
Owner
Copy Link

@aaronjwood commented on GitHub (Jan 2, 2021):

Yeah, you need to add cache=mmap mount option for this to work if you're using 9p mounts. The mmap call is what is failing here. I had to change the cache setting to get Plex to work too which is also using a 9p mount (their sqlite instance is what is calling mmap) so I decided to just apply cache=mmap to my setup.

@aaronjwood commented on GitHub (Jan 2, 2021): Yeah, you need to add `cache=mmap` mount option for this to work if you're using 9p mounts. The mmap call is what is failing here. I had to change the cache setting to get Plex to work too which is also using a 9p mount (their sqlite instance is what is calling mmap) so I decided to just apply `cache=mmap` to my setup.
GiteaMirror commented 2025-11-02 05:39:59 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 2, 2021):

@aaronjwood Thanks for the clarify.

I will summary something here for the three issue indexer types, bleve, db and elasticsearch. BTW: For code indexer types, there are only bleve and elasticsearch.

  • bleve is the default currently and it's only suitable for single Gitea instance and don't share the indexer data with other programs. A local filesystem is recommended.
  • db is low efficient which use database's indexer feature but you can share between Gitea instances. This is only for issue indexer.
  • elasticsearch will use an elasticsearch instance or cluster to do index and search. You can share between Gitea instances. But there are also something should be improved here. All Gitea instances may check if the indexer has been created when first start.
@lunny commented on GitHub (Jan 2, 2021): @aaronjwood Thanks for the clarify. I will summary something here for the three issue indexer types, `bleve`, `db` and `elasticsearch`. BTW: For code indexer types, there are only `bleve` and `elasticsearch`. - `bleve` is the default currently and it's only suitable for single Gitea instance and **don't share the indexer data with other programs**. A local filesystem is recommended. - `db` is low efficient which use database's indexer feature but you can share between Gitea instances. This is only for issue indexer. - `elasticsearch` will use an elasticsearch instance or cluster to do index and search. You can share between Gitea instances. But there are also something should be improved here. All Gitea instances may check if the indexer has been created when first start.
GiteaMirror commented 2025-11-02 05:39:59 -06:00
Author
Owner
Copy Link

@safag05 commented on GitHub (Jun 14, 2021):

I am trying to change my repo indexer to elasticsearch however Gitea tries to restart over and over again. On the logs I see this: Error: health check timeout: no Elasticsearch node available Do I need to set up Elastic Search node separately from Gitea in order to use it? Isn't just enabling REPO_INDEXER_TYPE = elasticsearch not sufficient?

@safag05 commented on GitHub (Jun 14, 2021): I am trying to change my repo indexer to elasticsearch however Gitea tries to restart over and over again. On the logs I see this: `Error: health check timeout: no Elasticsearch node available` Do I need to set up Elastic Search node separately from Gitea in order to use it? Isn't just enabling `REPO_INDEXER_TYPE = elasticsearch` not sufficient?
GiteaMirror commented 2025-11-02 05:39:59 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 14, 2021):

see https://docs.gitea.io/en-us/config-cheat-sheet/#indexer-indexer

@lunny commented on GitHub (Jun 14, 2021): see https://docs.gitea.io/en-us/config-cheat-sheet/#indexer-indexer
GiteaMirror commented 2025-11-02 05:39:59 -06:00
Author
Owner
Copy Link

@safag05 commented on GitHub (Jun 14, 2021):

Thanks for sharing that @lunny I have been looking into that already but I am noob on this indexer. I have the following in my app.ini and it is failing
REPO_INDEXER_ENABLED = true
REPO_INDEXER_TYPE = elasticsearch
REPO_INDEXER_PATH = indexers/repos.elasticsearch

I see that there is a config for REPO_INDEXER_CONN_STR is that something that I need to configure as well? It has an example of http://elastic:changeme@localhost:9200 but not sure where to get such URL from.

@safag05 commented on GitHub (Jun 14, 2021): Thanks for sharing that @lunny I have been looking into that already but I am noob on this indexer. I have the following in my app.ini and it is failing `REPO_INDEXER_ENABLED = true` `REPO_INDEXER_TYPE = elasticsearch` `REPO_INDEXER_PATH = indexers/repos.elasticsearch` I see that there is a config for `REPO_INDEXER_CONN_STR` is that something that I need to configure as well? It has an example of `http://elastic:changeme@localhost:9200` but not sure where to get such URL from.
GiteaMirror commented 2025-11-02 05:40:00 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 15, 2021):

When REPO_INDEXER_TYPE = elasticsearch, you should use REPO_INDEXER_CONN_STR

@lunny commented on GitHub (Jun 15, 2021): When `REPO_INDEXER_TYPE = elasticsearch`, you should use `REPO_INDEXER_CONN_STR`
GiteaMirror commented 2025-11-02 05:40:00 -06:00
Author
Owner
Copy Link

@safag05 commented on GitHub (Jun 15, 2021):

Sorry just to clarify as I am noob with this. In order to use REPO_INDEXER_CONN_STR I would need elastic search up and running right? And will need to use it's URL to connect it to Gitea via REPO_INDEXER_CONN_STR?

@safag05 commented on GitHub (Jun 15, 2021): Sorry just to clarify as I am noob with this. In order to use `REPO_INDEXER_CONN_STR` I would need elastic search up and running right? And will need to use it's URL to connect it to Gitea via `REPO_INDEXER_CONN_STR`?
GiteaMirror commented 2025-11-02 05:40:00 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Oct 21, 2021):

See https://docs.gitea.io/en-us/config-cheat-sheet/#indexer-indexer. I will close this issue currently because it's upstream related and there are some workrounds.

@lunny commented on GitHub (Oct 21, 2021): See https://docs.gitea.io/en-us/config-cheat-sheet/#indexer-indexer. I will close this issue currently because it's upstream related and there are some workrounds.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/confirmed type/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#4137
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?