GPG 2.4.7 locking problem

Werner Koch wk at gnupg.org
Mon Nov 10 14:51:01 CET 2025


On Fri,  7 Nov 2025 10:08, Max Allan said:

> When those processes are killed the lock file remains. EVEN if you ran the
> import with "--lock-never"

Oh, I forgot about this old option.  This may lead to all kind of
problems because it entirely disables the locking module for all kind of
locks.  We use file locks to protect the launching of daemons (gpg-agent,
keyboxd, dirmngr) as weel as to protect pubring.gpg and pubring.kbx
files.

> -rw-r--r--    2 root     root            24 Nov  7 09:56
> /root/.gnupg/public-keys.d/pubring.db.lock

and also to lock the sqlite database pubring.db so that only one keyboxd
process may use it.  There should be only one which is assured by using
a lock when launching keyboxd.

On Unix you may cat the file to see which process holds the lock.

> If you were in an "image build" process the keyboxd and gpg-agent processes
> would be killed. And they don't remove the lockfile. And when the image is

That depends on how you kill them; SIGKILL will for sure not clean them
up.  However we employ a stale lock removal method which works if the
lockfile has ben created on the same node (using uname(2)) but the
process does not anymore exist.

> Second: Terminating the process (without using gpgconf) does not remove the
> unwanted lockfile.

Try "gpgconf -K all" or send the SIGTERM more than 2 times to each
daemon.

> I did ask on Stackoverflow  with a full example in Alpine, but didn't get
> any responses yet.

Sorry, no time to read the log.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251110/b9376538/attachment.sig>


More information about the Gnupg-devel mailing list