branch lock file exists after push timeout #14525

New Issue

GiteaMirror · 2025-11-02T11:15:18-06:00

GiteaMirror commented

2025-11-02 11:15:18 -06:00

Originally created by @wondersd on GitHub (May 27, 2025).

Description

After a push failed due to timeout, a lock file remains on the branch that is preventing further pushes.

Original failure

$ git push origin main -f
Enumerating objects: 48, done.
Counting objects: 100% (48/48), done.
Delta compression using up to 4 threads
Compressing objects: 100% (34/34), done.
Writing objects: 100% (44/44), 14.33 KiB | 1.43 MiB/s, done.
Total 44 (delta 0), reused 0 (delta 0), pack-reused 0
error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
Everything up-to-date

Subsequent Pushes

$ git push origin main -f
Enumerating objects: 48, done.
Counting objects: 100% (48/48), done.
Delta compression using up to 4 threads
Compressing objects: 100% (34/34), done.
Writing objects: 100% (44/44), 14.33 KiB | 1.79 MiB/s, done.
Total 44 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: cannot lock ref 'refs/heads/main': Unable to create '/data/git/gitea-repositories/..././refs/heads/main.lock': File exists.
remote: 
remote: Another git process seems to be running in this repository, e.g.
remote: an editor opened by 'git commit'. Please make sure all processes
remote: are terminated then try again. If it still fails, a git process
remote: may have crashed in this repository earlier:
remote: remove the file manually to continue.

I'm sure the original issue timeout is just because this is running in a resource constrained environment

Looked through the Site Administration jobs and none of the seem to indicate that they would clean this.

Seems tangentially related to #32018 with this being another source of stale locks

Was able to manually remove the lock above and another lock that was also created for the same repo ./HEAD.lock and this allowed subsequent pushes to continue

Gitea Version

1.22.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.45.2

Operating System

docker container

How are you running Gitea?

kubernetes via gitea helm chart

Database

PostgreSQL

Originally created by @wondersd on GitHub (May 27, 2025). ### Description After a push failed due to timeout, a lock file remains on the branch that is preventing further pushes. Original failure ``` $ git push origin main -f Enumerating objects: 48, done. Counting objects: 100% (48/48), done. Delta compression using up to 4 threads Compressing objects: 100% (34/34), done. Writing objects: 100% (44/44), 14.33 KiB | 1.43 MiB/s, done. Total 44 (delta 0), reused 0 (delta 0), pack-reused 0 error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 send-pack: unexpected disconnect while reading sideband packet fatal: the remote end hung up unexpectedly Everything up-to-date ``` Subsequent Pushes ``` $ git push origin main -f Enumerating objects: 48, done. Counting objects: 100% (48/48), done. Delta compression using up to 4 threads Compressing objects: 100% (34/34), done. Writing objects: 100% (44/44), 14.33 KiB | 1.79 MiB/s, done. Total 44 (delta 0), reused 0 (delta 0), pack-reused 0 remote: error: cannot lock ref 'refs/heads/main': Unable to create '/data/git/gitea-repositories/..././refs/heads/main.lock': File exists. remote: remote: Another git process seems to be running in this repository, e.g. remote: an editor opened by 'git commit'. Please make sure all processes remote: are terminated then try again. If it still fails, a git process remote: may have crashed in this repository earlier: remote: remove the file manually to continue. ``` I'm sure the original issue timeout is just because this is running in a resource constrained environment Looked through the Site Administration jobs and none of the seem to indicate that they would clean this. Seems tangentially related to #32018 with this being another source of stale locks Was able to manually remove the lock above and another lock that was also created for the same repo `./HEAD.lock` and this allowed subsequent pushes to continue ### Gitea Version 1.22.1 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.45.2 ### Operating System docker container ### How are you running Gitea? kubernetes via gitea helm chart ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 11:15:18 -06:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14525