freyjagp/blog.raer.me
1
0
Fork 0
Code Actions Packages Releases Activity

Push blog entry for today.
Some checks failed
/ Connect to deployment host, update, and redeploy docs website. (push) Has been skipped
Details
/ Build static site, docker image, upload artifact... (push) Failing after 1m16s
Details

Browse Source
This commit is contained in:
Freyja Odinthrir
2025-09-10 19:42:12 -07:00
parent 772bf54b85
commit 22346caeda
1 changed files with 39 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
content/2025/09/10/blog-entry-192851.md Normal file
View File

@@ -0,0 +1,39 @@
title: An annoying issue with gitea
description: messing around with gitea stuff gets me into a wild goose chase.
tags: devops, gitea, sysadmin
date: 2025-09-10 19:28
# An annoying issue with gitea
Had this really frustrating issue today with gitea that I ultimately discovered was caused by a stale gpg lock file residing in a place I didn't expect.
It started out with me creating some orgs to better manage my personal forks. I have a few repositories that are forks of things from github, but not reflected as such in gitea. I started by making an org for github.com, migrating the repos there, renaming and archiving my copies, forking the repos to my gitea user, then pushing my local copy back to gitea. This allows me to maintain a local mirror of the github copy, and link to it as a fork in gitea. Pure semantics, honestly.
However there was this big issue when trying to view commit graphs on anything I've forked: I would ultimately get a timeout error & no page. Some prodding revealed gitea throwing this error multiple times before timeout:
```
2025/09/11 02:10:12 ...mmit_verification.go:229:ParseCommitWithSignature() [E] Error getting default signing key: ******** unable to get default signing key: ********, gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: WARNING: nothing exported
gpg: key export failed: Operation timed out
, exec(68c22f7a-13:gpg -a --export) failed: exit status 2(<nil>) stdout: stderr: gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
gpg: WARNING: nothing exported
gpg: key export failed: Operation timed out
```
Some cursory web searches showed that this wasn't something other people have encountered. Then a bit of about the error revealed that this was caused by a stale lock file. Simple enough, I thought. So I navigate to my gitea instance's data directory. I delete `data/git/.gnupg/public-keys.d/pubring.db.lock` only to STILL have the issue. WTF???
So after some more searching and using chatgpt... I find from some github issue that there's a second `.gnupg` dir!!! Seems that gitea uses gnupg in two different contexts requiring two gnupghome directories. Neat. Cool. Awesome.
So finally, I delete `data/gitea/data/home/.gnupg/public-keys.d/pubring.db.lock` and BADDA BING BADDA BOOM! BOBS UR AUNTIE! Problem solved!
Sigh. What a waste of the last hour or so of my life. 'least the issue is fixed and I can view commit graphs again! Somehow, this also fixed a load time issue when loading mirror repos. It should also fix a long standing issue I had with merging pull requests on gitea's webui!
- Freyja (2025-09-10 19:41)