Page MenuHome GnuPG

gpgme_cancel() does not stop gpg process from finishing asynchronous call
Closed, ResolvedPublic


Forwarding a Debian bug report. Citing:

Starting asynchronouse call and then canceling it with gpgme_cancel do cause
gpgme_wait() return Canceled error but leaves gpg process working and
finishing the call.

Attached is a slightly modified t-genkey test from the gpgme source showing
the problem.


External Link

Event Timeline

dleidert set External Link to 13 2012, 10:10 PM
dleidert set Version to 1.0.2.
dleidert added projects: Debian, Bug Report, gpgme.

You mean there is a useless process running which should better be killed, right?

1.0.2 is more than 8 years old. The code chnaged a lot in the meantime. Feel
free to re-open if the problems persists with 1.4.x?

werner claimed this task.
werner added a project: Too Old.

Can you please take a look at it again? If I compile long_genkey.c and run it
via ./long_genkey async it leaves a process behind, which should better be killed:

ps aux | grep gpg
dl 7577 7.0 0.0 24416 1924 pts/2 SL 22:05 0:00 gpg
--enable-special-filenames --use-agent --batch --no-sk-comment --lc-messages
de_DE.utf8 --lc-ctype de_DE.utf8 --status-fd 4 --no-tty --charset utf8
--enable-progress-filter --display :0 --ttyname /dev/pts/2 --ttytype xterm
--gen-key -- -&5

dleidert changed Version from 1.0.2 to 1.4.2.

Hm. The process disappears after some time. Maybe it just needs some time to
finish. Maybe not a bug anymore. Please take a look at it yourself.

I assume this is related to T1630 which has been fixed

GnuPG 2.1.11 will print PROGRESS lines which allows in connection with
--exit-on-status-write-error to use that correctly. We should add that option
to gpg invocation of gpgme, though.

Oops; forgot to add the fix to 1.7.0

werner removed a project: In Progress.
werner added a project: Unreleased.