-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
always running processes from 1.15.3 #17138
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
Comments
This is a duplicate report.
That will then tell you what bit of code opened these processes and we'll be able to figure out where the missing close is. |
As this is from the latest version and I can't find the issue number (right now) that this duplicates - I am going to reopen. @dannyzcy - could you please go to the admin page I mentioned above and show me the processes table at the bottom of the monitor page. That will allow us to figure out what is opening these processes. Then we will need to correlate the times with the logs as per https://docs.gitea.io/en-us/logging-configuration/#debugging-problems |
The picture above may already be the processes table at the bottom of the monitor page? right? logs:
|
I just tried, can not reproduce this problem on my side (Gitea 1.15.3 + Windows) May you get a full stack trace? It would help much. Steps:
|
That process list indicates to me that there's a deadlock somewhere in the hook. I'm confused as to how or where. I guess we're going to need to add some extra logging into: Lines 133 to 399 in 7ce938b
|
@dannyzcy if I were able to provide patches would you be able to recompile gitea and report the logs? The PPROF results that @wxiaoguang mentioned would also be helpful. |
@wxiaoguang The logs is as follows:
|
I can't always reproduce this bug sometime appear sometime disappear and not always the same repository I don't know how to recompile gitea sorry |
Is it blocked by internal push update router? |
New discovery different source: services/pull/pull.go:212 PPROF results:
|
I think we might need to pass the outputs of the profiles through pprof ourselves. if you give us the files obtained from:
We may be able to divine where the deadlock is occurring. you may need to zip these up. |
5 files are in zip file, thanks |
From the goroutine list, I guess:
I am not sure about pipe behaviors in Windows. If the pipes in Linux are closed, the git process will exit. But the above stack trace shows that even the pipes in Windows are closed, the git process still exists. Or maybe the pipes are not really closed? |
So that cancel will cancel the parent context of the running git process which should cause it to be killed. |
There is clearly some problem with the git process not being killed or terminated despite us cancelling everything. I don't think that cat-file usually has an associated autogc - I guess that could be a cause?! We could add some belt and braces |
I have no idea right now.
Maybe we can try
And maybe we need more logs when running git cli. |
|
I just can't think of why windows would keep the process around - could it be that there's unread content in one of the pipes and that's doing it?! I think TerminateProcess is fine in this case because cat-file --batch and cat-file --batch-check are supposed to be read-only - |
This would be fine for the cat-file --batch and batch-check commands but without more information as to what's causing the problem I can't help but worry that other processes are going to hang too. I do wonder if the issue is something to do with the pipes. One thing we do is we use So @dannyzcy are you able to run a few tests for us? I can provide two PRs (and provide builds of):
|
I think these two patches can be tried in one build, just add some error logs before ps: I haven't noticed the difference between 'io.Pipe' and 'os.Pipe', it surprised me .... |
Of course, my pleasure. |
In go-gitea#17138 it appears that on Windows a git cat-file can fail to be killed. This PR attempts to prevent this by: 1. Using os.Pipes for the input - this should mean that the stdin is definitely closed. 2. If the cat-file is doesn't close properly it will attempt to kill it repeatedly logging this. Fix go-gitea#17138 Signed-off-by: Andrew Thornton <[email protected]>
Backport go-gitea#17154 In go-gitea#17138 it appears that on Windows a git cat-file can fail to be killed. This PR attempts to prevent this by: 1. Using os.Pipes for the input - this should mean that the stdin is definitely closed. 2. If the cat-file is doesn't close properly it will attempt to kill it repeatedly logging this. Fix go-gitea#17138 Signed-off-by: Andrew Thornton <[email protected]>
The first push is the same problem, but I tried to push the second time and it was successful logs:
pprof files: |
OK the I'm just not sure what's going on or why these processes aren't shutting down. |
I have run that version for 3 hours I will continue to observe and report back |
Did you get any logs with: "still running 10s after cancellation. Reattempt Kill" in them? |
Running till now (7 hours), i am not get that log. |
I just don't understand it. There's nothing really changed to help stop that from happening. The only thing I can think of is some weird race that the changes have prevented. I'm gonna make one more change to the PR - dropping the Kill goroutine. |
https://eldritchkitty.com/~andrew/gitea-v1.15.3-14-g68100a6f2-pr-17155-windows-4.0-amd64.exe.xz This closes just one end of the pipe and removes the terminate go-routine. |
i get error with 'still running 10s after cancellation. Reattempt Kill'
logs
pprof: |
let me try the version |
I'm really not sure what's going on here. This looks to be either some bug in go, git or Windows. Are you using a virus checker? I'm really struggling for what else we can do. I don't have any real idea as to what's causing Windows to keep the process around and clearly from your invalid argument error we can't just kill the process again as the handle becomes invalid. I guess we could try to get the handle straight after starting but that is likely racy. It might be that closing both ends of the pipe is the problem so maybe this last version solves that? Otherwise: Are you sure that there isn't some bug in your git version? Could this be an antivirus issue? (The last version I uploaded just ensures that only one end of the pipes gets closed but the reattempt closer has been removed so you're stuck checking for blocked processes manually.) |
My gitea upgrade from 1.14.5 to 1.15.0 on 8/24, and found #17007 Then I upgraded git from 2.32.0 to 2.33.0 to try to fix This problem was discovered when upgrading to 1.15.3 on 9/22 No blocked process was found before 1.14.5 Except for git & gitea to upgrade, other server environments have not been adjusted I checked my virus checker without any log |
The last version still have a blocked process logs & pprof: maybe i should install git 2.32.0 to try |
May be worth trying 2.32 - the other option is that the problem is related to go 1.17 I guess |
i installed Git 2.32.0 have the same problem. |
OK I'm stumped. Genuinely stumped. Some more questions?
I don't see any reason why our code is causing this and I can't think of anymore ways of attempting to workaround the issue. |
To that end I'm going to push up a build of 1.15.4 with go 1.17 in case the issue is simply a go1.16 bug. https://www.eldritchkitty.com/~andrew/gitea-v1.15.4-go1.17-windows-4.0-amd64.exe.xz |
maybe MSYS2 git
I still have the same problem, can you help me try it with go 1.15?
No, I always download gitea from the official blog |
I run 1.15.6 with git 2.33.1 for 2 days, |
Ok I'm closing - I don't think we'll ever find out what was the problem. |
Gitea Version
1.15.3
Git Version
2.33.0.windows.2
Operating System
windows
How are you running Gitea?
running gitea by gitea-1.15.3-windows-4.0-amd64.exe
Database
MySQL
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Description
always running processes from 1.15.3
the bug from 1.15.3
not appear in 1.15.2
Screenshots
The text was updated successfully, but these errors were encountered: