Merge conflict checking in progress. Try again in a few minutes #9002

@silentcodeg commented on GitHub (May 27, 2022):

Do you remember at which version of Gitea the problem started to show? That would help narrow down the cause.

@silentcodeg commented on GitHub (May 27, 2022): Do you remember at which version of Gitea the problem started to show? That would help narrow down the cause.

GiteaMirror commented

@stu1811 commented on GitHub (May 27, 2022):

I want to say sometime in the 1.15.X series but it's worse in the past few 1.16.X. Side note I tried updating our git from 2.24.1 to 2.36.0 and it didn't help.

@stu1811 commented on GitHub (May 27, 2022): I want to say sometime in the 1.15.X series but it's worse in the past few 1.16.X. Side note I tried updating our git from 2.24.1 to 2.36.0 and it didn't help.

GiteaMirror commented

@silentcodeg commented on GitHub (May 27, 2022):

Is there a way for you to reproduce the problem and capture the gitea logs when you do? Or does it happen randomly?

@silentcodeg commented on GitHub (May 27, 2022): Is there a way for you to reproduce the problem and capture the gitea logs when you do? Or does it happen randomly?

GiteaMirror commented

2025-11-02 08:25:25 -06:00

@stu1811 commented on GitHub (May 27, 2022):

Which logging should I enable? The current logs aren't very helpful.

[Log]
MODE = file
LEVEL = error
ROUTER_LOG_LEVEL = error

[Server]
DISABLE_ROUTER_LOG = true

[Database]
LOG_SQL = false

Edit: It seems to happen after our main branch is updated. Normally the Update Branch button would be available at this point.
Edit 2: Not sure if it matters but we're using LFS.

@stu1811 commented on GitHub (May 27, 2022): Which logging should I enable? The current logs aren't very helpful. ``` [Log] MODE = file LEVEL = error ROUTER_LOG_LEVEL = error [Server] DISABLE_ROUTER_LOG = true [Database] LOG_SQL = false ``` Edit: It seems to happen after our main branch is updated. Normally the Update Branch button would be available at this point. Edit 2: Not sure if it matters but we're using LFS.

GiteaMirror commented

@stu1811 commented on GitHub (May 27, 2022):

The server is on separate network so I'm manually copying things over.

..dules/git/command.go:146:RunWithContent() [D] /PATH/TO/REPO.git: /usr/bin/git -c credential.helper= -c protocol.version=2 -c uploadpack.allowfilter=true -c uploadpack.allowAnySHA1Want=true -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean=merge-base --refs/heads/main refs/pull/1654/head
..dules/git/command.go:246:RunInDirTimeutEnv() [T] Stdout: <SHA>

@stu1811 commented on GitHub (May 27, 2022): The server is on separate network so I'm manually copying things over. ``` ..dules/git/command.go:146:RunWithContent() [D] /PATH/TO/REPO.git: /usr/bin/git -c credential.helper= -c protocol.version=2 -c uploadpack.allowfilter=true -c uploadpack.allowAnySHA1Want=true -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean=merge-base --refs/heads/main refs/pull/1654/head ..dules/git/command.go:246:RunInDirTimeutEnv() [T] Stdout: <SHA> ```

GiteaMirror commented

2025-11-02 08:25:25 -06:00

@silentcodeg commented on GitHub (May 29, 2022):

This is unfortunately too little information to figure out the cause of the problem. If someone could take a look at the full logs and run some tests with the live instance I'm pretty sure there is a simple explanation.

@silentcodeg commented on GitHub (May 29, 2022): This is unfortunately too little information to figure out the cause of the problem. If someone could take a look at the full logs and run some tests with the live instance I'm pretty sure there is a simple explanation.

GiteaMirror commented

2025-11-02 08:25:25 -06:00

@99rgosse commented on GitHub (May 31, 2022):

Hello
We ran into the same issue lately, and I think this is linked to (the zombie processes here)[https://github.com/go-gitea/gitea/issues/19077] with docker

All those 5 zombie processes are git child of Gitea, running since 22 days for the older ones. (I am still with v1.16.5 under docker & PGsql)

Here is what you get when you restart the container :

I will try to check this with a test instance

@99rgosse commented on GitHub (May 31, 2022): Hello We ran into the same issue lately, and I think this is linked to (the zombie processes here)[https://github.com/go-gitea/gitea/issues/19077] with docker ![image](https://user-images.githubusercontent.com/61579380/171138576-1439fdf4-3608-43c2-bd06-bd79ec2c41cc.png) All those 5 zombie processes are git child of Gitea, running since 22 days for the older ones. (I am still with v1.16.5 under docker & PGsql) Here is what you get when you restart the container : ![image](https://user-images.githubusercontent.com/61579380/171138824-f478ec51-6e34-4b52-89f8-780653da93ae.png) I will try to check this with a test instance

GiteaMirror commented

@silentcodeg commented on GitHub (May 31, 2022):

This indeed is an issue that seems to be eluding everyone for years. A few bug fixes were applied in this area but there never was a proper bug report on the matter and the root cause is still here, evidently.

Yet, there is a simple way to figure it out if someone was able to get access to a live instance where it happens and the corresponding logs. In your case @99rgosse, the next time it happens, would you be able to investigate further? Looking at the logs from when the zombie git process was launched, trying to figure out which zombie process relates to which operation in Gitea, trying to correlate which task is pending for a long time and why etc. It is tedious but it will lead to a bug report that will be a solid basis for a definitive bug fix.

@silentcodeg commented on GitHub (May 31, 2022): This indeed is an issue that seems to be eluding everyone for years. A few bug fixes were applied in this area but there never was a proper bug report on the matter and the root cause is still here, evidently. Yet, there is a simple way to figure it out if someone was able to get access to a live instance where it happens and the corresponding logs. In your case @99rgosse, the next time it happens, would you be able to investigate further? Looking at the logs from when the zombie git process was launched, trying to figure out which zombie process relates to which operation in Gitea, trying to correlate which task is pending for a long time and why etc. It is tedious but it will lead to a bug report that will be a solid basis for a definitive bug fix.

GiteaMirror commented

@stu1811 commented on GitHub (May 31, 2022):

@silentcodeg I'm not sure if this is related or a separate issue. If I a edit a file from the gitea website, create a PR, and then make another edit to the same file on the branch, I get "This pull request is broken due to missing fork information." I reproduced it on the demo site.
https://try.gitea.io/developers/foobar/pulls/6

@stu1811 commented on GitHub (May 31, 2022): @silentcodeg I'm not sure if this is related or a separate issue. If I a edit a file from the gitea website, create a PR, and then make another edit to the same file on the branch, I get "This pull request is broken due to missing fork information." I reproduced it on the demo site. https://try.gitea.io/developers/foobar/pulls/6

GiteaMirror commented

https://github.com/go-gitea/gitea/issues/19077#issuecomment-1141930825

@silentcodeg commented on GitHub (May 31, 2022):

@zeripath just posted a comment here:

that brings some clarity on this topic. In a nutshell, with 1.17 a significant amount of code was modified to:

prevent that kind of problem
facilitate the diagnostic of that kind of problem from the admin panel

@silentcodeg commented on GitHub (May 31, 2022): @zeripath just posted a comment here: https://github.com/go-gitea/gitea/issues/19077#issuecomment-1141930825 that brings some clarity on this topic. In a nutshell, with 1.17 a significant amount of code was modified to: * prevent that kind of problem * facilitate the diagnostic of that kind of problem from the admin panel

GiteaMirror commented

@silentcodeg commented on GitHub (May 31, 2022):

@silentcodeg I'm not sure if this is related or a separate issue. If I a edit a file from the gitea website, create a PR, and then make another edit to the same file on the branch, I get "This pull request is broken due to missing fork information." I reproduced it on the demo site. https://try.gitea.io/developers/foobar/pulls/6

This is unrelated and would be worth a separate bug report: the reproducer your provide will allow for a quick fix 👍

@silentcodeg commented on GitHub (May 31, 2022): > @silentcodeg I'm not sure if this is related or a separate issue. If I a edit a file from the gitea website, create a PR, and then make another edit to the same file on the branch, I get "This pull request is broken due to missing fork information." I reproduced it on the demo site. https://try.gitea.io/developers/foobar/pulls/6 This is unrelated and would be worth a separate bug report: the reproducer your provide will allow for a quick fix :+1:

GiteaMirror commented

@lunny commented on GitHub (May 31, 2022):

Hello We ran into the same issue lately, and I think this is linked to (the zombie processes here)[https://github.com//issues/19077] with docker

All those 5 zombie processes are git child of Gitea, running since 22 days for the older ones. (I am still with v1.16.5 under docker & PGsql)

Here is what you get when you restart the container :

I will try to check this with a test instance

Please upgrade to v1.16.8

@lunny commented on GitHub (May 31, 2022): > Hello We ran into the same issue lately, and I think this is linked to (the zombie processes here)[https://github.com/[/issues/19077](https://github.com/go-gitea/gitea/issues/19077)] with docker ![image](https://user-images.githubusercontent.com/61579380/171138576-1439fdf4-3608-43c2-bd06-bd79ec2c41cc.png) > > All those 5 zombie processes are git child of Gitea, running since 22 days for the older ones. (I am still with v1.16.5 under docker & PGsql) > > Here is what you get when you restart the container : ![image](https://user-images.githubusercontent.com/61579380/171138824-f478ec51-6e34-4b52-89f8-780653da93ae.png) > > I will try to check this with a test instance Please upgrade to v1.16.8

GiteaMirror commented

@99rgosse commented on GitHub (May 31, 2022):

Please upgrade to v1.16.8

I will :)
I did not have time to try yet the upgrade on my test server... I'm always cautious !

@99rgosse commented on GitHub (May 31, 2022): > Please upgrade to v1.16.8 I will :) I did not have time to try yet the upgrade on my test server... I'm always cautious !

GiteaMirror commented

@stu1811 commented on GitHub (May 31, 2022):

@zeripath just posted a comment here:

#19077 (comment)

that brings some clarity on this topic. In a nutshell, with 1.17 a significant amount of code was modified to:

prevent that kind of problem

facilitate the diagnostic of that kind of problem from the admin panel

I build 1.17 dev and my PR that was previously stuck is no longer stuck 🥳

EDIT: There is one error in the log.
patch_unmerged.go:131:unmergedFIles() [E] Unable to run ls-files -u -z! Error: git ls-files -u -z: signal: interrupt

@stu1811 commented on GitHub (May 31, 2022): > @zeripath just posted a comment here: > > [#19077 (comment)](https://github.com/go-gitea/gitea/issues/19077#issuecomment-1141930825) > > that brings some clarity on this topic. In a nutshell, with 1.17 a significant amount of code was modified to: > > * prevent that kind of problem > * facilitate the diagnostic of that kind of problem from the admin panel I build 1.17 dev and my PR that was previously stuck is no longer stuck 🥳 EDIT: There is one error in the log. `patch_unmerged.go:131:unmergedFIles() [E] Unable to run ls-files -u -z! Error: git ls-files -u -z: signal: interrupt`

GiteaMirror commented

@stu1811 commented on GitHub (May 31, 2022):

Sorry for the double post. One of my PRs is stuck with 1.17.0+dev-634-ge31c6166e.

Here is the stack trace

<>GET:/FOO/BAR/pulls/1234 (dead process)
<> database/sql.(*DB).connectionCleaner graceful-lifecycle with-hammer process-type request

- runtime.gopark

/usr/local/go/src/runtime/proc.go:366

- runtime.selectgo

/usr/local/go/src/runtime/select.go:327

- database.sql.(*DB).connectionCleaner

/usr/local/go/src/database/sql/sql.go:1068

Another dead process

<GET> /FOO/BAR/Issues:1234/content-history/overview?_csrf=.... (dead process)
<github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1 graceful-lifecycle with-hammer process-type request
- runtime.gopark

/usr/local/go/src/runtime/proc.go:366

- runtime.selectgo

/usr/local/go/src/runtime/select.go:327

- github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1

/home/stu/go/pkg/mod/github.com/go-sql-driver@v1.6.0/connection.go:614

@stu1811 commented on GitHub (May 31, 2022): Sorry for the double post. One of my PRs is stuck with 1.17.0+dev-634-ge31c6166e. Here is the stack trace ``` <>GET:/FOO/BAR/pulls/1234 (dead process) <> database/sql.(*DB).connectionCleaner graceful-lifecycle with-hammer process-type request - runtime.gopark /usr/local/go/src/runtime/proc.go:366 - runtime.selectgo /usr/local/go/src/runtime/select.go:327 - database.sql.(*DB).connectionCleaner /usr/local/go/src/database/sql/sql.go:1068 ``` Another dead process ``` <GET> /FOO/BAR/Issues:1234/content-history/overview?_csrf=.... (dead process) <github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1 graceful-lifecycle with-hammer process-type request - runtime.gopark /usr/local/go/src/runtime/proc.go:366 - runtime.selectgo /usr/local/go/src/runtime/select.go:327 - github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1 /home/stu/go/pkg/mod/github.com/go-sql-driver@v1.6.0/connection.go:614 ```

GiteaMirror commented

https://github.com/go-gitea/gitea/issues/19818#issuecomment-1142083599

@zeripath commented on GitHub (May 31, 2022):

@stu1811 Let me deal with these last two comments first:

EDIT: There is one error in the log.

EDIT: There is one error in the log.
patch_unmerged.go:131:unmergedFIles() [E] Unable to run ls-files -u -z! Error: git ls-files -u -z: signal: interrupt

signal: interrupt implies that something has killed the os process running git ls-files -u -z - either the parent context has been killed - e.g. you killed the process in the table or you cancelled a cherry-pick request - or... possibly it timed out.

There would be more interesting logs above/around this if there was a timeout. But a single logline isn't really enough to help us to help you.

Go-routines labelled with `(dead process)`

https://github.com/go-gitea/gitea/issues/19818#issuecomment-1142110259

Goroutines labelled (dead process) are not necessarily a problem. They do need examination but this label does not mean what you think it means.

We label each goroutine created by Gitea with a marker of where it was created.

When requests come in we label its goroutine with a pprof label to trace any goroutines it creates and the goroutine itself with that request.

Now that in these cases the request has caused a new longlived DB connection to occur and because that code/library does not relabel its goroutines it is still associated with the request.

In the meantime the request has been dealt with and its process closed but the DB connection and its goroutines remain - hence their association with the "dead" process. This is annoying but not a problem.

Stacktraces

`database.sql.(*DB).connectionCleaner /usr/local/go/src/database/sql/sql.go:1068`

<>GET:/FOO/BAR/pulls/1234 (dead process)
<> database/sql.(*DB).connectionCleaner graceful-lifecycle with-hammer process-type request

- runtime.gopark

/usr/local/go/src/runtime/proc.go:366

- runtime.selectgo

/usr/local/go/src/runtime/select.go:327

- database.sql.(*DB).connectionCleaner

/usr/local/go/src/database/sql/sql.go:1068

This is simply related to the DB connection pool cleaner as you would see if you looked at the code. This is not a problem.

`github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1 /home/stu/go/pkg/mod/github.com/go-sql-driver@v1.6.0/connection.go:614`

<GET> /FOO/BAR/Issues:1234/content-history/overview?_csrf=.... (dead process)
<github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1 graceful-lifecycle with-hammer process-type request
- runtime.gopark

/usr/local/go/src/runtime/proc.go:366

- runtime.selectgo

/usr/local/go/src/runtime/select.go:327

- github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1

/home/stu/go/pkg/mod/github.com/go-sql-driver@v1.6.0/connection.go:614

Again an internal goroutine related to DB connection management.

Hanging Git Processes (or How to use the stacktraces tab correctly to identify a hanging git processes)

If there are "hanging" git OS processes these will be attached to very likely non-dead Gitea processes & requests. The associated process will have a goroutine labelled os/exec.Start() or something like that.

To truly identify a hanging git os process the stacktrace should be there for a while AND the process should not die after clicking on the 🗑️ icon.

If you are concerned that there are hanging processes - give us the whole trace unless you really know what you're looking at.

The webpage output is fine but gitea manager processes --stacktraces will emit a text output of this data.

How to help us with " One of my PRs is stuck with 1.17.0+dev-634-ge31c6166e."

I need logs.

I'm gonna need to read the rest of this thread as I've been very busy recently and I've missed it however you've provided us with just too little information to help you.

I need logs.

I don't understand why we have to repeatedly paste this: https://docs.gitea.io/en-us/logging-configuration/#debugging-problems

and copy and paste this:

[database]
LOG_SQL = false ; SQL logs are rarely helpful unless we specifically ask for them

...

[log]
MODE = console
LEVEL = debug ; please set the level to debug when we are debugging a problem
ROUTER = console
COLORIZE = false ; this can be true if you can strip out the ansi coloring
ENABLE_SSH_LOG = true ; shows logs related to git over SSH.

When you open a bug report the template very clearly asks you to do this. What can we do to make this clearer?

Do we need to put this in huge letters?

Can you please give me some logs after you've pushed a change and the pr has got stuck?

@zeripath commented on GitHub (May 31, 2022): @stu1811 Let me deal with these last two comments first: ## EDIT: There is one error in the log. https://github.com/go-gitea/gitea/issues/19818#issuecomment-1142083599 > EDIT: There is one error in the log. > patch_unmerged.go:131:unmergedFIles() [E] Unable to run ls-files -u -z! Error: git ls-files -u -z: signal: interrupt `signal: interrupt` implies that something has killed the os process running `git ls-files -u -z` - either the parent context has been killed - e.g. you killed the process in the table or you cancelled a cherry-pick request - or... possibly it timed out. There would be more interesting logs above/around this if there was a timeout. But a single logline isn't really enough to help us to help you. ## Go-routines labelled with `(dead process)` https://github.com/go-gitea/gitea/issues/19818#issuecomment-1142110259 Goroutines labelled `(dead process)` are not necessarily a problem. They do need examination but this label does not mean what you think it means. We label each goroutine created by Gitea with a marker of where it was created. When requests come in we label its goroutine with a pprof label to trace any goroutines it creates and the goroutine itself with that request. Now that in these cases the request has caused a new longlived DB connection to occur and because that code/library does not relabel its goroutines it is still associated with the request. In the meantime the request has been dealt with and its process closed but the DB connection and its goroutines remain - hence their association with the "dead" process. This is annoying but not a problem. <details><summary>Stacktraces</summary> ## `database.sql.(*DB).connectionCleaner /usr/local/go/src/database/sql/sql.go:1068` ``` <>GET:/FOO/BAR/pulls/1234 (dead process) <> database/sql.(*DB).connectionCleaner graceful-lifecycle with-hammer process-type request - runtime.gopark /usr/local/go/src/runtime/proc.go:366 - runtime.selectgo /usr/local/go/src/runtime/select.go:327 - database.sql.(*DB).connectionCleaner /usr/local/go/src/database/sql/sql.go:1068 ``` This is simply related to the DB connection pool cleaner as you would see if you looked at the code. This is not a problem. ## `github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1 /home/stu/go/pkg/mod/github.com/go-sql-driver@v1.6.0/connection.go:614` ``` <GET> /FOO/BAR/Issues:1234/content-history/overview?_csrf=.... (dead process) <github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1 graceful-lifecycle with-hammer process-type request - runtime.gopark /usr/local/go/src/runtime/proc.go:366 - runtime.selectgo /usr/local/go/src/runtime/select.go:327 - github.com/go-sql-driver/mysql.(*mysqlConn).startWatcher.func1 /home/stu/go/pkg/mod/github.com/go-sql-driver@v1.6.0/connection.go:614 ``` Again an internal goroutine related to DB connection management. </details> ## Hanging Git Processes (or How to use the stacktraces tab correctly to identify a hanging git processes) If there are "hanging" git OS processes these will be attached to very likely non-dead Gitea processes & requests. The associated process will have a goroutine labelled os/exec.Start() or something like that. To truly identify a hanging git os process the stacktrace should be there for a while AND the process should not die after clicking on the :wastebasket: icon. If you are concerned that there are hanging processes - give us the whole trace unless you really know what you're looking at. The webpage output is fine but `gitea manager processes --stacktraces` will emit a text output of this data. ## How to help us with " One of my PRs is stuck with 1.17.0+dev-634-ge31c6166e." I need logs. I'm gonna need to read the rest of this thread as I've been very busy recently and I've missed it however you've provided us with just too little information to help you. I need logs. I don't understand why we have to repeatedly paste this: https://docs.gitea.io/en-us/logging-configuration/#debugging-problems and copy and paste this: ```ini [database] LOG_SQL = false ; SQL logs are rarely helpful unless we specifically ask for them ... [log] MODE = console LEVEL = debug ; please set the level to debug when we are debugging a problem ROUTER = console COLORIZE = false ; this can be true if you can strip out the ansi coloring ENABLE_SSH_LOG = true ; shows logs related to git over SSH. ``` When you open a bug report the template very clearly asks you to do this. What can we do to make this clearer? Do we need to put this in huge letters? Can you please give me some logs after you've pushed a change and the pr has got stuck?

GiteaMirror commented

@zeripath commented on GitHub (May 31, 2022):

@silentcodeg I'm not sure if this is related or a separate issue. If I a edit a file from the gitea website, create a PR, and then make another edit to the same file on the branch, I get "This pull request is broken due to missing fork information." I reproduced it on the demo site. https://try.gitea.io/developers/foobar/pulls/6

This is unrelated and would be worth a separate bug report: the reproducer your provide will allow for a quick fix +1

This was due a misconfiguration on the try.gitea.io docker setup - see below.

OLD STUFF

I agree that this is unrelated but - I'm not going to pretend that this is a quick fix...

The problem is interesting because I cannot replicate it locally and so I think it's related to another problem on try that I do not completely understand.

If I add trace logging in I can't see an update message.

OH I BET THIS HAS SOMETHING TO DO WITH PROC-RECEIVE - nope...

@zeripath commented on GitHub (May 31, 2022): > > @silentcodeg I'm not sure if this is related or a separate issue. If I a edit a file from the gitea website, create a PR, and then make another edit to the same file on the branch, I get "This pull request is broken due to missing fork information." I reproduced it on the demo site. https://try.gitea.io/developers/foobar/pulls/6 > > This is unrelated and would be worth a separate bug report: the reproducer your provide will allow for a quick fix +1 This was due a misconfiguration on the try.gitea.io docker setup - see below. <details><summary> OLD STUFF </summary> I agree that this is unrelated but - I'm not going to pretend that this is a quick fix... The problem is interesting because I cannot replicate it locally and so I think it's related to another problem on try that I do not completely understand. If I add trace logging in I can't see an update message. OH I BET THIS HAS SOMETHING TO DO WITH PROC-RECEIVE - nope... </details>

GiteaMirror commented

@zeripath commented on GitHub (May 31, 2022):

~~PushToBaseRepo is only in proc-receive which is not definitely going to always be run.~~ -- nope that's not it.

The post-receive hook does not appear to be being run... Actually no hooks appear to be being run.

The problem is that the script is failing at:

test -x "${hook}" && test -f "${hook}" || continue

I bet this another seccomp issue on docker...

Yup... the docker version running try.gitea.io is old.

FIXED.

@zeripath commented on GitHub (May 31, 2022): ~~PushToBaseRepo is only in proc-receive which is not definitely going to always be run.~~ -- nope that's not it. The post-receive hook does not appear to be being run... Actually no hooks appear to be being run. The problem is that the script is failing at: ```bash test -x "${hook}" && test -f "${hook}" || continue ``` I bet this another seccomp issue on docker... Yup... the docker version running try.gitea.io is old. FIXED.

GiteaMirror commented

https://github.com/go-gitea/gitea/pull/18050

@zeripath commented on GitHub (May 31, 2022):

OK @stu1811 if you're getting the same problem on your local instance your problem is that your docker version is too old.

See:

See: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0 & https://about.gitlab.com/blog/2021/08/26/its-time-to-upgrade-docker-engine/

@zeripath commented on GitHub (May 31, 2022): OK @stu1811 if you're getting the same problem on your local instance your problem is that your docker version is too old. See: https://github.com/go-gitea/gitea/pull/18050 See: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0 & https://about.gitlab.com/blog/2021/08/26/its-time-to-upgrade-docker-engine/

GiteaMirror commented

2025-11-02 08:25:29 -06:00

@stu1811 commented on GitHub (May 31, 2022):

OK @stu1811 if you're getting the same problem on your local instance your problem is that your docker version is too old.

See:

#18050

See: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0 & https://about.gitlab.com/blog/2021/08/26/its-time-to-upgrade-docker-engine/

I actually don't see it locally since I run it bare metal. I ran into this issue while trying to reproduce the issue in the OP on the demo site.

@stu1811 commented on GitHub (May 31, 2022): > OK @stu1811 if you're getting the same problem on your local instance your problem is that your docker version is too old. > > See: > > #18050 > > See: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0 & https://about.gitlab.com/blog/2021/08/26/its-time-to-upgrade-docker-engine/ I actually don't see it locally since I run it bare metal. I ran into this issue while trying to reproduce the issue in the OP on the demo site.

GiteaMirror commented

2025-11-02 08:25:29 -06:00

@singuliere commented on GitHub (May 31, 2022):

Do we need to put this in huge letters?

You are looking at the problem in the wrong way.

If someone has a service contract that guarantees the confidentiality of the data won't be exposed publicly, they will be in a position to diagnose the problem. You could be that person. Otherwise every person reporting a bug is compelled to edit what they think are the relevant parts of the logs and the database content to not expose confidential information to third parties that are not trusted. And the selection they make is bound to hide the relevant information most of the time.

@singuliere commented on GitHub (May 31, 2022): > Do we need to put this in huge letters? You are looking at the problem in the wrong way. If someone has a service contract that guarantees the confidentiality of the data won't be exposed publicly, they will be in a position to diagnose the problem. You could be that person. Otherwise every person reporting a bug is compelled to edit what they think are the relevant parts of the logs and the database content to not expose confidential information to third parties that are not trusted. And the selection they make is bound to hide the relevant information most of the time.

GiteaMirror commented

@zeripath commented on GitHub (May 31, 2022):

@singuliere I'm talking about repeated comments like: https://github.com/go-gitea/gitea/issues/19818#issuecomment-1139794607 - this happens all the time.

We can't help if we don't see any logs and it's crazy the number of times we have to post the same app.ini section from the linked document. If the issue template is not clear we need to make it clearer.

I can suggest a slight improvement on the app.ini suggestion above:

[database]
LOG_SQL = false ; SQL logs are rarely helpful unless we specifically ask for them

...

[log]
MODE = console, traceconsole
LEVEL = debug ; please set the level to debug when we are debugging a problem
ROUTER = console
COLORIZE = false ; this can be true if you can strip out the ansi coloring
ENABLE_SSH_LOG = true ; shows logs related to git over SSH.

[log.traceconsole]
MODE=console
LEVEL=trace
EXPRESSION=services/pull

Then at least you'd see some messages like:

[T] PullRequest[%d].testPatch (patchPath): %s

which could be used to trace the patch testing process.

@zeripath commented on GitHub (May 31, 2022): @singuliere I'm talking about repeated comments like: https://github.com/go-gitea/gitea/issues/19818#issuecomment-1139794607 - this happens all the time. We can't help if we don't see any logs and it's crazy the number of times we have to post the same app.ini section from the linked document. If the issue template is not clear we need to make it clearer. --- I can suggest a slight improvement on the app.ini suggestion above: ```ini [database] LOG_SQL = false ; SQL logs are rarely helpful unless we specifically ask for them ... [log] MODE = console, traceconsole LEVEL = debug ; please set the level to debug when we are debugging a problem ROUTER = console COLORIZE = false ; this can be true if you can strip out the ansi coloring ENABLE_SSH_LOG = true ; shows logs related to git over SSH. [log.traceconsole] MODE=console LEVEL=trace EXPRESSION=services/pull ``` Then at least you'd see some messages like: ``` [T] PullRequest[%d].testPatch (patchPath): %s ``` which could be used to trace the patch testing process.

GiteaMirror commented

@singuliere commented on GitHub (May 31, 2022):

@singuliere I'm talking about repeated comments like: #19818 (comment) - this happens all the time.

Oh, I see. In that case maybe moving this from point 6. in the list to point 1. in the template would help ?

This is off topic though, sorry for the noise.

@singuliere commented on GitHub (May 31, 2022): > @singuliere I'm talking about repeated comments like: [#19818 (comment)](https://github.com/go-gitea/gitea/issues/19818#issuecomment-1139794607) - this happens all the time. Oh, I see. In that case maybe moving this from point 6. in the list to point 1. in the template would help ? This is off topic though, sorry for the noise.

GiteaMirror commented

@stu1811 commented on GitHub (Jul 26, 2022):

We've run 1.16.8 for a while now and the issues seems much better. Sometimes PRs do get stuck for about 30 minutes but eventually do recover and the update branch/merge buttons become available. One thing I noticed is while stuck some PRs have a red merge arrow and others have a yellow merge arrow. I'm not sure if that's of any significance.

@stu1811 commented on GitHub (Jul 26, 2022): We've run 1.16.8 for a while now and the issues seems much better. Sometimes PRs do get stuck for about 30 minutes but eventually do recover and the update branch/merge buttons become available. One thing I noticed is while stuck some PRs have a red merge arrow and others have a yellow merge arrow. I'm not sure if that's of any significance.

GiteaMirror commented