3.3 KiB
| layout | title | date | tags | excerpt | categories | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| post | Fixing GPG Lock Issues | 2024-06-23 13:00:00 -0400 |
|
Fixing GPG Lock Issues | 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!