Skip to content

Gitea crashes at start: pthread_create failed #6031

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 of 7 tasks
bodqhrohro opened this issue Feb 10, 2019 · 17 comments
Closed
3 of 7 tasks

Gitea crashes at start: pthread_create failed #6031

bodqhrohro opened this issue Feb 10, 2019 · 17 comments
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented

Comments

@bodqhrohro
Copy link

Description

Screenshots

@lafriks
Copy link
Member

lafriks commented Feb 10, 2019

Do you have code search enabled?

@bodqhrohro
Copy link
Author

I have not done any configuration yet, just downloaded the binary and tried to run it. Do you mean REPO_INDEXER_ENABLED, which is disabled by default?

@lafriks
Copy link
Member

lafriks commented Feb 10, 2019

yes

@bodqhrohro
Copy link
Author

So, no; the auto-generated config has only INTERNAL_TOKEN defined.

@jolheiser
Copy link
Member

Could be related to this issue?
Some CGO threads leaking/not returning?

@typeless
Copy link
Contributor

Is this reliably reproducible on every launch of Gitea? Or does it happen randomly?

@bodqhrohro
Copy link
Author

Could be related to this issue?
Some CGO threads leaking/not returning?

Probably. So I need to make a custom build with CGO_ENABLED=0? Or it would be better to check if pthread_create is permitted on the hosting first?

Is this reliably reproducible on every launch of Gitea? Or does it happen randomly?

On every launch on certain system.

@typeless
Copy link
Contributor

typeless commented Feb 11, 2019

@bodqhrohro I tested it on Ubuntu 14.04 through docker, and it works. apt-get upgrade your libc and so on might help if it is a library issue (the released Gitea binary seems to be a static executable, so it should have nothing to do with libc).

@TraceyC77
Copy link

I started seeing the same error when trying to use git push to push up changes over ssh with gitea 1.7.4. The error is still present with 1.8. I had not experienced any problems doing git push before 1.7.4.

Gitea version (or commit ref): 1.8
System Git version: 2.21
Git version reported in log/gitea.log: Git Version: 1.8.3.1
Operating system: CentOS 7.6.1810 (Core)

The service is running OK according to systemd.
The website loads and I don't see any issues when using it.

Gist of log

@lunny
Copy link
Member

lunny commented Mar 30, 2019

@TraceyC77 did you use sqlite database?

@TraceyC77
Copy link

TraceyC77 commented Mar 30, 2019 via email

@zeripath
Copy link
Contributor

@TraceyC77 I'm not sure if this is the cause of your issue but it's certainly bad to have Gitea using that old a git version. Clearly you still have git 1.8 installed somewhere.

I remember reading about git 1.8 on centos before causing trouble however I can't find the issue that had this right now.

@TraceyC77
Copy link

I got some time to look into this a little further. My gitea service is on a cPanel server, which late last year added its own git repo UI. There had been these two git binaries, but removing the older one did not resolve the issue. I don't use the cPanel git repo feature, I only use gitea for my repos. My gitea server used to work perfectly until recently.

When I looked for git binaries, there was /usr/bin/git as well as

# which git
/usr/local/cpanel/3rdparty/lib/path-bin/git

After removing the non-cPanel provided git with "yum remove git" and restarting the gitea service I got:

 ❯ git push                                                                                                        [17:23:27]
Gitea: Internal error
Failed to get repository: Get http://localhost:8888/api/internal/repo/$owner/$repo: dial tcp [::1]:8888: connect: connection refused
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

If I reinstall the CentOS provided git with "yum install git" I'm back to the original error
remote: runtime/cgo: pthread_create failed: Resource temporarily unavailable

I've looked through the logs and config and really can't find anything to nail this down further. I'm willing to provide more information if requested.

@typeless
Copy link
Contributor

@TraceyC77 Can you check if the cpanel git is a binary or something like a shell-script wrapper?
Not sure if that matters or not, but it's suspicious that your default git location is not /usr/bin/git.

If that is the case, @lunny's idea about having the path of git customizable in app.ini can neatly solve the issue.

@lunny
Copy link
Member

lunny commented Apr 20, 2019

@typeless We need a PR to do that.

@TraceyC77
Copy link

@TraceyC77 Can you check if the cpanel git is a binary or something like a shell-script wrapper?
Not sure if that matters or not, but it's suspicious that your default git location is not /usr/bin/git.

Both git files are binaries. The second git binary is not suspicious at all on a cPanel server, this is expected. As I had mentioned, cPanel added its own git server capabilities.

If that is the case, @lunny's idea about having the path of git customizable in app.ini can neatly solve the issue.

It turns out that wasn't the problem. My gitea server is now working properly, so I wanted to share what I did to solve it in case it helps @bodqhrohro

  • Updated to gitea 1.8.0 - this is what I think solved the pthread_create error
  • After this I was getting the error
    remote: panic: Git version missing: fork/exec /usr/local/cpanel/3rdparty/libexec/git-core/git: resource temporarily unavailable
    This was solved by disabling Fork Bomb Protection in WHM (this is unrelated to the original problem, including for completeness).

@stale
Copy link

stale bot commented Jun 24, 2019

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 stale bot added the issue/stale label Jun 24, 2019
@lunny lunny added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label Jun 25, 2019
@stale stale bot removed the issue/stale label Jun 25, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented
Projects
None yet
Development

No branches or pull requests

8 participants