pre-receive takes a long time to finish on push #12190

@lunny commented on GitHub (Dec 13, 2023):

I can find two slow log.

2023/12/12 20:06:32 ...eb/routing/logger.go:68:func1() [W] router: slow      POST /taggerei/taggerei.git/git-receive-pack for [::1]:61556, elapsed 3698.7ms @ repo/githttp.go:500(repo.ServiceReceivePack)

and

2023/12/12 20:06:39 ...dules/git/command.go:345:Run() [D] slow git.Command.Run: "C:\\Program Files\\Git\\cmd\\git.exe" -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc C:\gitea\data\gitea-repositories\taggerei\taggerei.git (9.7827557s)

@lunny commented on GitHub (Dec 13, 2023): I can find two slow log. ```log 2023/12/12 20:06:32 ...eb/routing/logger.go:68:func1() [W] router: slow POST /taggerei/taggerei.git/git-receive-pack for [::1]:61556, elapsed 3698.7ms @ repo/githttp.go:500(repo.ServiceReceivePack) ``` and ```log 2023/12/12 20:06:39 ...dules/git/command.go:345:Run() [D] slow git.Command.Run: "C:\\Program Files\\Git\\cmd\\git.exe" -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc C:\gitea\data\gitea-repositories\taggerei\taggerei.git (9.7827557s) ```

GiteaMirror commented

@PulsarFX commented on GitHub (Dec 13, 2023):

I think this is the birds eye view. The client is sitting and waiting for the server to return. All data has already been transfered.
In GitExtensions this looks like this:
First, the transfer is done and the cursor keeps on blinking for many seconds:

Then, finally it looks like this:

On our .net client the log looks like this:

2023-12-13 09:20:38.1418 [  3]  INFO  GitService: Push Start for repo .\\taggerei\sources\(xycv) -> http://localhost:3000/taggerei/taggerei.git(refs/heads/xycv) 
2023-12-13 09:20:38.2320 [  3] DEBUG  GitService: git push: 0 of 6 objects sent to server. 12 bytes sent to the server. (Elapsed: 00:00:00.0880108) 
2023-12-13 09:20:50.3128 [  3] DEBUG  GitService: git push: 6 of 6 objects sent to server. 1216 bytes sent to the server. (Elapsed: 00:00:12.1687881) 
2023-12-13 09:20:50.3638 [  3]  INFO  GitService: Push Finished for repo .\\taggerei\sources\ (Elapsed: 00:00:12.2197249)

From all the tests I've done so far, it looks like the delay comes from the pre-receive hook, when gitea starts itself again (shown in the first screenshot).
Is there a way to see what is happening in there? Or can I disable hooks alltogether?
My guess is, that it's a kind of timeout because of user restrictions, when gitea is run as windows service.

For reference, a perfect run looks like this:

2023-12-13 09:39:27.7926 [  6]  INFO  GitService: Push Start for repo .\\taggerei\sources\(xycv) -> http://localhost:3000/taggerei/taggerei.git(refs/heads/xycv) 
2023-12-13 09:39:27.8610 [  6] DEBUG  GitService: git push: 0 of 6 objects sent to server. 12 bytes sent to the server. (Elapsed: 00:00:00.0663798) 
2023-12-13 09:39:28.4928 [  6] DEBUG  GitService: git push: 6 of 6 objects sent to server. 1218 bytes sent to the server. (Elapsed: 00:00:00.6982429) 
2023-12-13 09:39:28.5437 [  6]  INFO  GitService: Push Finished for repo .\\taggerei\sources\ (Elapsed: 00:00:00.7490811)

In this scenario, the second gitea.exe shows up only fractions of time in ProcessExplorer or it's even to short to show up in the list at all.

I don't think the RUN_USER has any affect on this issue. Today it was 12s again when the service runs as Local System. When I use my account instead to start the windows service, it's 0,7s every time on each client.
Then also my user is executing the pre-receive:
C:\gitea\gitea-1.21.1-gogit-windows-4.0-amd64.exe hook --config=C:\gitea\custom\conf\app.ini pre-receive

@PulsarFX commented on GitHub (Dec 13, 2023): I think this is the birds eye view. The client is sitting and waiting for the server to return. All data has already been transfered. In GitExtensions this looks like this: First, the transfer is done and the cursor keeps on blinking for many seconds: ![grafik](https://github.com/go-gitea/gitea/assets/4960210/6609c461-9bcc-43e4-a8f1-db98094f5cb0) Then, finally it looks like this: ![grafik](https://github.com/go-gitea/gitea/assets/4960210/53ad0ff0-c50c-4bcb-99e1-b744a163fc81) On our .net client the log looks like this: ``` 2023-12-13 09:20:38.1418 [ 3] INFO GitService: Push Start for repo .\\taggerei\sources\(xycv) -> http://localhost:3000/taggerei/taggerei.git(refs/heads/xycv) 2023-12-13 09:20:38.2320 [ 3] DEBUG GitService: git push: 0 of 6 objects sent to server. 12 bytes sent to the server. (Elapsed: 00:00:00.0880108) 2023-12-13 09:20:50.3128 [ 3] DEBUG GitService: git push: 6 of 6 objects sent to server. 1216 bytes sent to the server. (Elapsed: 00:00:12.1687881) 2023-12-13 09:20:50.3638 [ 3] INFO GitService: Push Finished for repo .\\taggerei\sources\ (Elapsed: 00:00:12.2197249) ``` From all the tests I've done so far, it looks like the delay comes from the pre-receive hook, when gitea starts itself again (shown in the first screenshot). Is there a way to see what is happening in there? Or can I disable hooks alltogether? My guess is, that it's a kind of timeout because of user restrictions, when gitea is run as windows service. For reference, a perfect run looks like this: ``` 2023-12-13 09:39:27.7926 [ 6] INFO GitService: Push Start for repo .\\taggerei\sources\(xycv) -> http://localhost:3000/taggerei/taggerei.git(refs/heads/xycv) 2023-12-13 09:39:27.8610 [ 6] DEBUG GitService: git push: 0 of 6 objects sent to server. 12 bytes sent to the server. (Elapsed: 00:00:00.0663798) 2023-12-13 09:39:28.4928 [ 6] DEBUG GitService: git push: 6 of 6 objects sent to server. 1218 bytes sent to the server. (Elapsed: 00:00:00.6982429) 2023-12-13 09:39:28.5437 [ 6] INFO GitService: Push Finished for repo .\\taggerei\sources\ (Elapsed: 00:00:00.7490811) ``` In this scenario, the second gitea.exe shows up only fractions of time in ProcessExplorer or it's even to short to show up in the list at all. I don't think the RUN_USER has any affect on this issue. Today it was 12s again when the service runs as Local System. When I use my account instead to start the windows service, it's 0,7s every time on each client. Then also my user is executing the pre-receive: `C:\gitea\gitea-1.21.1-gogit-windows-4.0-amd64.exe hook --config=C:\gitea\custom\conf\app.ini pre-receive`

GiteaMirror commented

@PulsarFX commented on GitHub (Dec 18, 2023):

Is no one else experiencing this behaviour on a windows service? I found 2 or more tickets where problems with the windows service existed ( #15454 and #19053)
Currently I am running gitea with my user account, but this can't be the solution for this.

@PulsarFX commented on GitHub (Dec 18, 2023): Is no one else experiencing this behaviour on a windows service? I found 2 or more tickets where problems with the windows service existed ( #15454 and #19053) Currently I am running gitea with my user account, but this can't be the solution for this.

GiteaMirror commented

@lunny commented on GitHub (Dec 25, 2023):

Do you have real pre-receive scripts in those repositories?

@lunny commented on GitHub (Dec 25, 2023): Do you have real `pre-receive` scripts in those repositories?

GiteaMirror commented

@PulsarFX commented on GitHub (Dec 25, 2023):

No, these are naked hook repos

@PulsarFX commented on GitHub (Dec 25, 2023): No, these are naked hook repos

GiteaMirror commented

@PulsarFX commented on GitHub (Jan 11, 2024):

Is there something I can help with to investigate?
I just discovered, that using my domain user to run the service has a strong drawback: Windows can only run/start the service, if I am connected to our company vpn.

@PulsarFX commented on GitHub (Jan 11, 2024): Is there something I can help with to investigate? I just discovered, that using my domain user to run the service has a strong drawback: Windows can only run/start the service, if I am connected to our company vpn.

GiteaMirror commented

@lunny commented on GitHub (Jan 12, 2024):

Take a look at the logs again, it should not be related with Gitea's pre-receive hook handle. The consuming time is under the git command

2023/12/12 20:06:29 ...s/process/manager.go:188:Add() [T] Start 6578af35-11: C:\Program Files\Git\cmd\git.exe receive-pack --stateless-rpc [repo_path: C:\gitea\data\gitea-repositories\taggerei\taggerei.git] (from 6578af35-10) (normal)

and before Gitea's pre-receive invoked.

2023/12/12 20:06:29 ...s/process/manager.go:188:Add() [T] Start 6578af35-11: C:\Program Files\Git\cmd\git.exe receive-pack --stateless-rpc [repo_path: C:\gitea\data\gitea-repositories\taggerei\taggerei.git] (from 6578af35-10) (normal)
2023/12/12 20:06:32 ...eb/routing/logger.go:68:func1() [W] router: slow      POST /taggerei/taggerei.git/git-receive-pack for [::1]:61556, elapsed 3698.7ms @ repo/githttp.go:500(repo.ServiceReceivePack)
2023/12/12 20:06:38 ...s/process/manager.go:188:Add() [T] Start 6578af3e: POST: /api/internal/hook/pre-receive/taggerei/taggerei (request)

@lunny commented on GitHub (Jan 12, 2024): Take a look at the logs again, it should not be related with Gitea's pre-receive hook handle. The consuming time is under the git command ``` 2023/12/12 20:06:29 ...s/process/manager.go:188:Add() [T] Start 6578af35-11: C:\Program Files\Git\cmd\git.exe receive-pack --stateless-rpc [repo_path: C:\gitea\data\gitea-repositories\taggerei\taggerei.git] (from 6578af35-10) (normal) ``` and before Gitea's pre-receive invoked. ``` 2023/12/12 20:06:29 ...s/process/manager.go:188:Add() [T] Start 6578af35-11: C:\Program Files\Git\cmd\git.exe receive-pack --stateless-rpc [repo_path: C:\gitea\data\gitea-repositories\taggerei\taggerei.git] (from 6578af35-10) (normal) 2023/12/12 20:06:32 ...eb/routing/logger.go:68:func1() [W] router: slow POST /taggerei/taggerei.git/git-receive-pack for [::1]:61556, elapsed 3698.7ms @ repo/githttp.go:500(repo.ServiceReceivePack) 2023/12/12 20:06:38 ...s/process/manager.go:188:Add() [T] Start 6578af3e: POST: /api/internal/hook/pre-receive/taggerei/taggerei (request) ```

GiteaMirror commented

@PulsarFX commented on GitHub (Jan 12, 2024):

Which log do you mean? Is there another log, except what is set in app.ini?

[log]
ROOT_PATH = C:/gitea/log
LEVEL = warn
MODE = tofile

[log.tofile]
MODE = file
FILE_NAME = file.log

To recap: gitea runs absoluteley fine, when I start it from CLI. It bogs, when it runs as windows service with the default local system user.
For me this is screaming: "access rights problem".

In ...\hooks\pre-receive.d there is one file called gitea with this content:

#!/usr/bin/env bash
# AUTO GENERATED BY GITEA, DO NOT MODIFY
C:/gitea/gitea-1.21.1-gogit-windows-4.0-amd64.exe hook --config="C:\\gitea\\custom\\conf\\app.ini" pre-receive

This is the same call as I can see in ProcessExplorer sitting around, when it bogs.
I just switched to the system account and it bogs right away on the first try.
Then I removed the gitea file from the pre-receive.d folder. After this, it is this process sitting and waiting:

C:\gitea\gitea-1.21.1-gogit-windows-4.0-amd64.exe hook --config=C:\gitea\custom\conf\app.ini update refs/heads/jhgfd ffc906fe49bcefb59ad2125e4323c4f9a9685aa4 11a1df8d52e436e15b412538089fba0fe55424f8

Then I tried disabling all network connections. This doesn't have a clear effect.

@PulsarFX commented on GitHub (Jan 12, 2024): Which log do you mean? Is there another log, except what is set in app.ini? ``` [log] ROOT_PATH = C:/gitea/log LEVEL = warn MODE = tofile [log.tofile] MODE = file FILE_NAME = file.log ``` To recap: gitea runs absoluteley fine, when I start it from CLI. It bogs, when it runs as windows service with the default local system user. For me this is screaming: "access rights problem". In `...\hooks\pre-receive.d` there is one file called `gitea` with this content: ``` #!/usr/bin/env bash # AUTO GENERATED BY GITEA, DO NOT MODIFY C:/gitea/gitea-1.21.1-gogit-windows-4.0-amd64.exe hook --config="C:\\gitea\\custom\\conf\\app.ini" pre-receive ``` This is the same call as I can see in ProcessExplorer sitting around, when it bogs. I just switched to the system account and it bogs right away on the first try. Then I removed the gitea file from the `pre-receive.d` folder. After this, it is this process sitting and waiting: `C:\gitea\gitea-1.21.1-gogit-windows-4.0-amd64.exe hook --config=C:\gitea\custom\conf\app.ini update refs/heads/jhgfd ffc906fe49bcefb59ad2125e4323c4f9a9685aa4 11a1df8d52e436e15b412538089fba0fe55424f8` Then I tried disabling all network connections. This doesn't have a clear effect.

GiteaMirror commented

2025-11-02 10:01:33 -06:00

@AudivoRumplerA commented on GitHub (Oct 1, 2024):

It seems that I suffer from exactly the same problem. Pushes to gitea takes 15s or more.

I use:

gitea v1.22.2 (gitea-1.22.2-windows-4.0-amd64.exe)
Windows Server 2022
gitea runs as a service

Symptoms are as described above.

no matter which git client I use
no matter whethe I use SSL or no SSL
no matter wheter I acccess gitea from local network or via internet

PusarFX, did you meanwhile found a solution other than running gitea not as a service?

@AudivoRumplerA commented on GitHub (Oct 1, 2024): It seems that I suffer from exactly the same problem. Pushes to gitea takes 15s or more. I use: - gitea v1.22.2 (gitea-1.22.2-windows-4.0-amd64.exe) - Windows Server 2022 - gitea runs as a service Symptoms are as described above. - no matter which git client I use - no matter whethe I use SSL or no SSL - no matter wheter I acccess gitea from local network or via internet PusarFX, did you meanwhile found a solution other than running gitea not as a service?

GiteaMirror commented

@AudivoRumplerA commented on GitHub (Oct 1, 2024):

update..
I tested starting of gitea.exe from CLI. It is also slow. So for me no difference regardless gitea is started as service or from CLI.

@AudivoRumplerA commented on GitHub (Oct 1, 2024): update.. I tested starting of gitea.exe from CLI. It is also slow. So for me no difference regardless gitea is started as service or from CLI.

GiteaMirror commented

@PulsarFX commented on GitHub (Oct 1, 2024):

I am using the go-gitea version running as a service. The service user is a domain user, which made it much faster for me.
That was the result of my recap from above. I've had no other results since then.

@PulsarFX commented on GitHub (Oct 1, 2024): I am using the go-gitea version running as a service. The service user is a domain user, which made it much faster for me. That was the result of my recap from above. I've had no other results since then.

GiteaMirror commented

@AudivoRumplerA commented on GitHub (Oct 1, 2024):

Thanks for your update, PulsarFX.

I will see whether I could get any better performance by using the gogit version and running as different users.

@AudivoRumplerA commented on GitHub (Oct 1, 2024): Thanks for your update, PulsarFX. I will see whether I could get any better performance by using the gogit version and running as different users.

GiteaMirror commented

@lunny commented on GitHub (Oct 2, 2024):

Have you enabled antivirus software? Can you try disabling the antivirus software?

@lunny commented on GitHub (Oct 2, 2024): Have you enabled antivirus software? Can you try disabling the antivirus software?

GiteaMirror commented

@AudivoRumplerA commented on GitHub (Oct 2, 2024):

Yes, the server (windows server 2022) uses AVAST antivirus software.

With activated antivirus a push takes ~17sec.
When I disable antivirus then a push just takes 4-5sec.

So a major difference. So the antivirus software is actually the reason of the slow pushes. It seems that it is enough to exclude gitea.exe from file shield module of AVAST.

Thanks a lot for the hint, lunny.

@AudivoRumplerA commented on GitHub (Oct 2, 2024): Yes, the server (windows server 2022) uses AVAST antivirus software. With activated antivirus a push takes ~17sec. When I disable antivirus then a push just takes 4-5sec. So a major difference. So the antivirus software is actually the reason of the slow pushes. It seems that it is enough to exclude gitea.exe from file shield module of AVAST. Thanks a lot for the hint, lunny.

GiteaMirror commented