1

I keep getting a recurring problem in Fedora 41 and now 42 where the GPG database gets locked and nothing I try can get it working. I have to delete the .gnupg directory and re-import my keys all over again.

The problem manifests after a reboot and I discover it the next time I try and commit code to git.

I have tried:

  1. Killing the process.
  2. Rebooting.
  3. rm -f ~/.gnupg/*.lock
  4. gpgconf --kill all && gpgconf --launch gpg-agent

Additional info based on question below:

$ gpg --list-keys
gpg: Note: database_open 134217901 waiting for lock (held by 5289) ...
gpg: Note: database_open 134217901 waiting for lock (held by 5289) ...
gpg: Note: database_open 134217901 waiting for lock (held by 5289) ...
gpg: Note: database_open 134217901 waiting for lock (held by 5289) ...
gpg: Note: database_open 134217901 waiting for lock (held by 5289) ...
gpg: keydb_search_first failed: Connection timed out
$ lsof | grep 5289
$$ tree ~/.gnupg
/home/bryon/.gnupg
├── common.conf
├── private-keys-v1.d
│   ├── 3ED6F3A0FE32B7DFEC04340B9AFCDB4842DFDC85.key
│   ├── 6026F43FDF049972ED2ABFF215E85EB4937D6B45.key
│   ├── 81F8A0D8D0E9CD406AE2C89B16AA4D4E872A39AD.key
│   └── FAC9D0944809312FCD2EC1C5B3D9F79210AECF8D.key
├── public-keys.d
│   ├── pubring.db
│   └── pubring.db.lock
└── trustdb.gpg

3 directories, 8 files
$ lsof ~/.gnupg/public-keys.d/pubring.db.lock 
$ 
4
  • Reproduce it and check what process is holding it open. Commented Jun 16 at 7:19
  • Added detail above. Commented Jun 18 at 4:27
  • Have you changed your hostname lately? If so, this was reported to GnuPG and dismissed as not-a-bug, sadly; it triggers what you're seeing after a hostname change. I can reproduce it too, and I'm testing some non-destructive fixes here. Will post an answer if it works. Commented Aug 9 at 22:15
  • I won't be able to test this anymore as I had to change the distro, but I'll describe what I've attempted as a fix. First of all, kill existing processes with gpgconf --kill all. Now, inside ~/.gnupg/public-keys.d you may find, in addition to the zombie lock-file, a few hidden files with strange names. If you read their filenames closer, you'll see that each of them has a hostname — your hostname — near the end of it. Some of them reference your current hostname, but others reference the old one. My suggestion is to delete the files containing your old hostname, and the lock-file. Commented Aug 11 at 1:40

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.