-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Task running since 2 weeks #16113
Comments
Interesting - if there's no system git process related then there's no task - so somehow the process manager hasn't been informed that the process has died. In terms of your problem - if there's genuinely no system git process - just restart Gitea. |
I restarted Gitea yesterday. ;) I have logs. I check them for some errors. |
There isn't any git process
|
I can only restart Gitea. But the stop process need more than 2 minutes. Cause something hangs.
|
Looks like there is a problem with https://github.com/akka/doc.akka.io . |
That means the record hasn't been removed from processes list when process is end. |
Looks like. But gitea stop took too long. Something is blocked. I'm restarting my Gitea 1 or 2x in a month. Only if the reboot is required. |
@lunny I removed now this mirror to solve my "problem". But there is a bug in Gitea. You can close it or leave it open. |
@somera but I don't understand how this is happening. I just don't. Let's look at the code: Lines 122 to 171 in bb054fd
We create a context with its own cancel which will be cancelled at the end of the function. Then we set up the command We register the command and its cancel with the process manager and will be deregistered at the end of the function: Lines 155 to 156 in bb054fd
We then run the command and wait for it to end. When the command terminates - Go will tell us here: Line 167 in bb054fd
and so the deferred function at 156 will lead to the process being removed from the manager. If you click the So how does anything get stuck in the process manager? It doesn't make sense. |
My Gitea instance is updating the mirrors every 24h. This projest was a mirror. After some days the one mirror process in Gitea was "running". Stopping the process wasn't working. And there was no git linux process. And stopping gitea process in this case took longer as normaly. Like something was blocking. |
Yes I understand what you're saying but I still don't understand how this can be happening. The only place such a problem could occur is in If there's really no process in the OS table then why isn't cmd.Wait finishing? |
Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-80-generic x86_64) problem? I say no. Cause the probability that another repo would be affected would be higher. But what I saw was ... only the one specific repo has problem. You can add the mirror (https://github.com/akka/doc.akka.io.git) on your instance and take a look on this. I do this again.
Iwas not checking this every day. ;) Means, that I found it days later. Here #16113 (comment) you can see two mirror processes. On my Gitea instance I have 5804 mirrors. ~99% from GitHub. The sync process needs ~3h. If you makes too much requests to GitHub than you have to wait. I don't know what happens, when Gitea is updating so much repos in a row. Did you know this? But if there was a problem with GitHub other repos will be affected. |
Cancel the process should be fixed in 1.16.0. |
sorry, I can't confirm this, cause I'm using only the release version on my system. I try to setup new Gitea system for testing. |
I could'n test it. But today I checked it with Gitea 1.5.3 and it's worse than before. Mirror process is finished, but what I see is Try to mirror https://github.com/akka/doc.akka.io on your local instances. |
And than if you click on the trash the one git process will be killed and the CPU usage goes down. But the mirror entry on the admin/mirror page still exists. Should be reproducable for you. After I deleted the repo my Gitea needed a restart to remove the two mirror process from the admin/mirror page. |
I think I've finally discovered the underlying issue here: If git cat-file is run on a broken git repository instead of immediately fatalling it will hang until stdin is closed. This will result in dangling cat-file processes. Therefore #17991 (and the backport will fix this.) |
I don't think so. Most of the repositories are normal but not broken git repositories. |
…and other fixes (#17991) This PR contains multiple fixes. The most important of which is: * Prevent hang in git cat-file if the repository is not a valid repository Unfortunately it appears that if git cat-file is run in an invalid repository it will hang until stdin is closed. This will result in deadlocked /pulls pages and dangling git cat-file calls if a broken repository is tried to be reviewed or pulls exists for a broken repository. Fix #14734 Fix #9271 Fix #16113 Otherwise there are a few small other fixes included which this PR was initially intending to fix: * Fix panic on partial compares due to missing PullRequestWorkInProgressPrefixes * Fix links on pulls pages due to regression from #17551 - by making most /issues routes match /pulls too - Fix #17983 * Fix links on feeds pages due to another regression from #17551 but also fix issue with syncing tags - Fix #17943 * Add missing locale entries for oauth group claims * Prevent NPEs if ColorFormat is called on nil users, repos or teams.
…and other fixes (go-gitea#17991) This PR contains multiple fixes. The most important of which is: * Prevent hang in git cat-file if the repository is not a valid repository Unfortunately it appears that if git cat-file is run in an invalid repository it will hang until stdin is closed. This will result in deadlocked /pulls pages and dangling git cat-file calls if a broken repository is tried to be reviewed or pulls exists for a broken repository. Fix go-gitea#14734 Fix go-gitea#9271 Fix go-gitea#16113 Otherwise there are a few small other fixes included which this PR was initially intending to fix: * Fix panic on partial compares due to missing PullRequestWorkInProgressPrefixes * Fix links on pulls pages due to regression from go-gitea#17551 - by making most /issues routes match /pulls too - Fix go-gitea#17983 * Fix links on feeds pages due to another regression from go-gitea#17551 but also fix issue with syncing tags - Fix go-gitea#17943 * Add missing locale entries for oauth group claims * Prevent NPEs if ColorFormat is called on nil users, repos or teams.
Testes again with Gitea 1.16.6. Started mirror https://github.com/akka/doc.akka.io -> finished, but: without any process:
|
Will be fixed by #19454 |
The problem was finally found after #19207 was merged in to main however if we had been provided with a pprof goroutine dump from an affected instance with
The issue might have been able to be found and investigated quicker. I think this means that we need to add simple buttons for downloading pprofs etc and commands to get them from |
I attached the file: I downloaded it after the new mirror of the affected project. |
[x]
):Description
Just found today the task, which is running since 2 weeks. There is no system git process.
And it is not possible to remove it.
Screenshots
The text was updated successfully, but these errors were encountered: