serv process are not killed (SSHd) #3001

New Issue

GiteaMirror · 2025-11-02T04:56:48-06:00

GiteaMirror commented

2025-11-02 04:56:48 -06:00

Originally created by @bruestel on GitHub (Mar 4, 2019).

Gitea version (or commit ref): 1.7.3 built with go1.11.5 : bindata, sqlite, pam
Git version: 2.21.0
Operating system: Arch Linux
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/bruestel/6e94ac1229e7860230fc481f3e8f384c

Description

Our CI server is checking the git repositories every minute. After a couple of minutes (less than an hour) all the memory is used and the CPU load is very high.
It seems to me that with each ssh connection from our CI there is a new process (/usr/bin/gitea serv key-9 --config=/etc/gitea/app.ini) created. The process gets never disposed.

I've cleaned my logs (#4450) but it didn't help. I think it is a different problem.

Thanks for your help.

Originally created by @bruestel on GitHub (Mar 4, 2019). - Gitea version (or commit ref): 1.7.3 built with go1.11.5 : bindata, sqlite, pam - Git version: 2.21.0 - Operating system: Arch Linux - 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/bruestel/6e94ac1229e7860230fc481f3e8f384c ## Description Our CI server is checking the git repositories every minute. After a couple of minutes (less than an hour) all the memory is used and the CPU load is very high. It seems to me that with each ssh connection from our CI there is a new process (`/usr/bin/gitea serv key-9 --config=/etc/gitea/app.ini`) created. The process gets never disposed. I've cleaned my logs (#4450) but it didn't help. I think it is a different problem. Thanks for your help.

GiteaMirror added the type/question issue/stale labels 2025-11-02 04:56:48 -06:00

GiteaMirror closed this issue

2025-11-02 04:56:48 -06:00

GiteaMirror commented

2025-11-02 04:56:49 -06:00

@lunny commented on GitHub (Mar 17, 2019):

@bruestel yes, every ssh request will create a new process but it should be ended some seconds after finished it's work. So maybe you can find some logs to track why it did not end.

@lunny commented on GitHub (Mar 17, 2019): @bruestel yes, every ssh request will create a new process but it should be ended some seconds after finished it's work. So maybe you can find some logs to track why it did not end.

GiteaMirror commented

2025-11-02 04:56:49 -06:00

@stale[bot] commented on GitHub (May 16, 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[bot] commented on GitHub (May 16, 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.

GiteaMirror commented

2025-11-02 04:56:49 -06:00

@zeripath commented on GitHub (May 16, 2019):

Hmm... I suspect that these are due to deadlocked processes.

I think it's time to review serv.go again to check if there are deadlocks.

@zeripath commented on GitHub (May 16, 2019): Hmm... I suspect that these are due to deadlocked processes. I think it's time to review serv.go again to check if there are deadlocks.

GiteaMirror commented

2025-11-02 04:56:49 -06:00

@lunny commented on GitHub (May 16, 2019):

gitea serv will invoke git command and blocked util that command returned. If the command is blocked, it will always wait.

@lunny commented on GitHub (May 16, 2019): `gitea serv` will invoke `git` command and blocked util that command returned. If the command is blocked, it will always wait.

GiteaMirror commented

2025-11-02 04:56:49 -06:00

@zeripath commented on GitHub (May 16, 2019):

OK, So both serv and hook appear to be only using private urls which is good - but each action it does is within a new session. We may be better to actually just make serv and hook do all of their logic in a private url and then return their results in simplified fashion to serv/hook.

@zeripath commented on GitHub (May 16, 2019): OK, So both serv and hook appear to be only using private urls which is good - but each action it does is within a new session. We may be better to actually just make serv and hook do all of their logic in a private url and then return their results in simplified fashion to serv/hook.

GiteaMirror commented

2025-11-02 04:56:50 -06:00

@lunny commented on GitHub (May 17, 2019):

@zeripath I like your idea. But that may not the reason of this issue.

@lunny commented on GitHub (May 17, 2019): @zeripath I like your idea. But that may not the reason of this issue.

GiteaMirror commented

2025-11-02 04:56:50 -06:00

@zeripath commented on GitHub (May 17, 2019):

It depends on the cause I guess, and although moving the logic won't immediately fix what I suspect is the problem - it will help formulate the complete solution. (It should also make both serv and hook faster as they won't need to make multiple internal API requests - and we might be able to drop the gitlogger.)

I suspect that there's deadlock in hook caused by the calls to send the webhooks.

@zeripath commented on GitHub (May 17, 2019): It depends on the cause I guess, and although moving the logic won't immediately fix what I suspect is the problem - it will help formulate the complete solution. (It should also make both serv and hook faster as they won't need to make multiple internal API requests - and we might be able to drop the gitlogger.) I suspect that there's deadlock in hook caused by the calls to send the webhooks.

GiteaMirror commented

2025-11-02 04:56:50 -06:00

@stale[bot] commented on GitHub (Jul 16, 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[bot] commented on GitHub (Jul 16, 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.

GiteaMirror commented

2025-11-02 04:56:50 -06:00

@stale[bot] commented on GitHub (Jul 30, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Jul 30, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:16:54 -06:00

[PR #3001] [MERGED] Remove duplicate "Max Diff Lines" from config view #16709

GiteaMirror referenced this issue

2025-11-02 12:20:01 -06:00

[PR #3209] [CLOSED] Please check the following: #16827

Sign in to join this conversation.