---
layout: post
title:  "Fixing GPG Lock Issues"
date:   2024-06-23 13:00:00 -0400
tags: [gpg, gnu, troubleshooting, linux, git, mac, mbp, osx]
excerpt: "Fixing GPG Lock Issues"
categories: osx linux gpg git
---

If you encounter a problem where you cannot commit your changes to git, you may be encountering a freeze during the commit process while it's trying to sign your commit.  This is often an issue with GPG being locked.

## How it all started

{% highlight bash %}
~/src/docker/container > git commit -m "bump version"
error: gpg failed to sign the data
fatal: failed to write commit object
{% endhighlight %}

## Try another GPG operation
{% highlight bash %}
~/src/docker/container > gpg --list-secret-keys --keyid-format=long
gpg: Note: database_open [id] waiting for lock (held by [pid]) ...
gpg: Note: database_open [id] waiting for lock (held by [pid]) ...
gpg: Note: database_open [id] waiting for lock (held by [pid]) ...
gpg: Note: database_open [id] waiting for lock (held by [pid]) ...
gpg: Note: database_open [id] waiting for lock (held by [pid]) ...
gpg: keydb_search_first failed: Operation timed out
{% endhighlight %}

Ok.  Now we have a clue, there is a lock held by `[pid]` preventing the gpg database from opening. Let's find out what the pid is.

## Find the pid
{% highlight bash %}
 696 : 2 : ~/src/docker/container > ps -elf | grep [pid]
  501  7122  3535     4006   0  31  0 34252392    748 -      R+                  0 ttys002    0:00.00 grep [pid]       12:46PM
{% endhighlight %}

Nothing other than our grep statement.  It appears that this lock is being held by a pid that no long has an active process.  Come to think of it, my mack did have a lockup this morning and I shut it down hard.  I'm sure this is where this is leftover from.

## Find a lock file containing our pid

{% highlight bash %}
~/src/docker/container > grep -r [pid] ~/.* 2> /dev/null
{% endhighlight %}

Let's break down what's happening here...

{% highlight bash %}
grep -r [pid]
{% endhighlight %}

Recursively find a file that matches [pid]

{% highlight bash %}
~/.*
{% endhighlight %}

The location we want to search (`~/` representing the home directory of the current user, `.*` is to search in files and directories starting with a `.` (AKA, hidden files and folders))

{% highlight bash %}
2> /dev/null
{% endhighlight %}

Send any errors to `/dev/null`

### The findings
After executing the previous command, here's what I found:

{% highlight bash %}
/Users/me/.gnupg/public-keys.d/.#ls0x00001111.hostname.local.[pid]: [pid]
/Users/me/.gnupg/public-keys.d/pubring.db.lock: [pid]
{% endhighlight %}

## Get the lock file out of the way
You could `rm -f` the file, but I prefer to move things out of the way to see what the outcome is before destruction.

{% highlight bash %}
~/src/docker/container > mv ~/.gnupg/public-keys.d/pubring.db.lock ~/.gnupg/public-keys.d/pubring.db.lock.bak
{% endhighlight %}

## Reload gpg agent
{% highlight bash %}
~/src/docker/container > gpgconf --reload gpg-agent
{% endhighlight %}

## Validate the fix
{% highlight bash %}
~/src/docker/container > gpg --list-secret-keys --keyid-format=long

[keyboxd]
---------
sec     [info]
        [info]
uid     [keyname]

...
{% endhighlight %}

## Retry commit in git
Now that the gpg problem is resolved, go back and try commiting your changes, this should have resolved them!