gpg-lock issue post

_posts/2024-06-23-fixing-gpg-lock-issues.md

@@ -0,0 +1,101 @@
+---
+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!