The Error keydb_search_first failed: Operation timed out

You run a routine gpg --list-secret-keys and get this:


gpg: Note: database_open 134217901 waiting for lock (held by 90379) ... gpg: Note: database_open 134217901 waiting for lock (held by 90379) ... gpg: Note: database_open 134217901 waiting for lock (held by 90379) ... gpg: Note: database_open 134217901 waiting for lock (held by 90379) ... gpg: Note: database_open 134217901 waiting for lock (held by 90379) ... gpg: keydb_search_first failed: Operation timed out

This is a stale lock file problem. GPG uses filesystem-level locks to prevent concurrent access to your keyring database. A previous GPG process crashed or was killed uncleanly — and it never released its lock. The PID it held (90379 in this case) no longer exists, but the lock file is still sitting on disk claiming ownership.

TL;DR: A dead process left a stale lock in ~/.gnupg/. Delete the lock files, restart the GPG agent, and you're done.

Why Does This Happen?

GPG's keybox database uses dotlock files — small .lock files written alongside the database containing the PID of the process currently accessing it. When GPG starts, it checks: is this PID still alive? If so, wait. If not, it should clean up — but it doesn't always.

Common causes:

  • A GPG operation was interrupted mid-flight (Ctrl+C, SIGKILL, system crash)
  • A git commit/sign operation was aborted before completion
  • A package manager triggered GPG verification that was forcefully terminated
  • The kernel's OOM killer terminated the GPG process

Step-by-Step Fix

Step 1 — Confirm the Process is Dead


kill -9 90379

# kill: kill 90379 failed: no such process

Getting "no such process" confirms it: the lock is an orphan. Move on.

Step 2 — Remove Stale Lock Files


# Remove all .lock files under ~/.gnupg

find ~/.gnupg -name "*.lock" -delete



# Remove dotfile lock sentinels

find ~/.gnupg -name ".#*" -delete

Step 3 — Restart the GPG Agent


gpgconf --kill gpg-agent

Step 4 — Verify


gpg --list-secret-keys --keyid-format=long

# Should now list your keys normally

Still Locked?

On some systems, lock files live deeper inside the keybox database directories. Target them explicitly:


rm -f ~/.gnupg/public-keys.d/*.lock

rm -f ~/.gnupg/private-keys-v1.d/*.lock



gpgconf --launch gpg-agent

gpg --list-secret-keys --keyid-format=long

⚠️ Never use rm -rf ~/.gnupg to fix this. That directory contains your private keys — deleting it means losing them permanently. Only remove *.lock files.

Prevention

There's no perfect fix — crashes happen. But these practices help:

  • Gracefully stop the agent before rebooting: gpgconf --kill gpg-agent
  • Avoid force-killing GPG mid-operation. Send SIGTERM before escalating to SIGKILL -9
  • Keep GPG updated — newer versions of gnupg2 have improved stale lock detection

The Full One-Liner

Bookmark this.


find ~/.gnupg -name "*.lock" -delete && \

find ~/.gnupg -name ".#*" -delete && \

gpgconf --kill gpg-agent && \

gpg --list-secret-keys --keyid-format=long