I created a Go test program that runs several Go routines, each of which verifies a byte array loaded from a file in advance. Each go-routine is spawned with a configurable delay in milliseconds. I tested it with 100 iterations, which resulted in at least 50 parallel processes. Each verification process uses its own context, as Crio does. I didn't encounter any errors.

Here is my repository with a README containing more information: https://git.sr.ht/~kulbartsch/gpgmego-verify-load-test

For issues of get_max_fds, I created a sub task, although it seems not the direct cause of this particular problem.

I test following test program (gcc -o t-gmf t-gmf.c) on Debian machine of S390x.

In the log, we can observe duplicated lines generated by
https://dev.gnupg.org/source/gpgme/browse/master/src/posix-io.c$545
Example is like:

2025-05-19 20:16:35 gpgme[21970.55d7]   _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1
2025-05-19 20:16:35 gpgme[21970.55d7]   _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1

No other processes that I have seen. However please see this last update by Kulbarsch. https://github.com/cri-o/cri-o/issues/8906#issuecomment-2936351035

@sj98ta
Does cri-o invokes processes (other than the ones of gpgme) by its threads?

I am not sure that I am clear on what you are asking. I am not an expert on cri-o, but is does seem that there are multiple processes (threads), which all call gpgme_op_verify There are also calls to gpgme_op_import

@sj98ta Please let us know if cri-o invokes other processes (except the ones by gpgme) or not.
If cri-o invokes other processes (by other threads), my theory matters; With the interference by other processes holding pipe file descriptors, gpgme keeps polling pipe file descriptors.

I have now seen instances where 1, 2, or 3 processes hang.

Re: pipe2: In gpgme_io_pipe we set FD_CLOEXEC only for one end of the pipe. Thus simply using pipe2 would change the behaviour.

Here is a hypothetical application which may have similar problem.
(1) It is a multi threaded application using gpgme, forking another process (possibly, exec).
(2) One of threads invokes gpgme_new, gpgme_op_import and gpg_op_verify.
(3) When the control goes to gpgme_op_* then gpgme_io_spawn by a thread A, another thread B forks a process.
(3-1) While the thread A is polling pipe I/O, forked process holds pipe file descriptors too.
(3-2) Until the forked process exists, pipe I/O polling by the thread A continues (because pipe's other end is still active).

There is FD_CLOFORK on Solaris 11.4 as well. It is a part of POSIX-1.2024, but who knows how long until that becomes common.

I don't know if it is related to this particular case, but I found a possible race condition in _gpgme_io_pipe.
Between pipe and fcntl with FD_CLOEXEC, another thread may fork a process which keeps running.
It would be good to use pipe2 here:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/pipe.html

Another possible cause is... gpgme uses closefrom in GNU C library, if available. if it doesn't work well, it would be possible invoked gpg keeps waiting its input.

Here is my observation.