[Pkg-gnupg-maint] Bug#694635: gnupg: gpg froze with a zombie after a Ctrl-C (intr character)

[Daniel Leidert]

Hi guys,

Vincent, you already reported this issue to us. According to what has
been written and said [1], the issue might be a bug in glibc [2].

Can you verify, that it is still the same issue? If yes, maybe you
should pick up the discussion at the point it was left in [2](?).

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614963#22
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399904

Regards, Daniel

Am Samstag, den 08.12.2012, 14:06 +0100 schrieb Vincent Lefevre:
> On 2012-12-07 17:09:31 +0100, Werner Koch wrote:
> > On Fri,  7 Dec 2012 16:31, vincent at vinc17.net said:
> > > When it receives a SIGINT, gpg should quit immediately (possibly
> > > after some clean-up). The problem is that gpg was still running.
> > 
> > Like Mutt, gpg has its own sigint handler.  It does some important
> > cleanups.
> 
> But after the cleanups, it should quit. This is not always the case
> (there is no CPU activity from gpg, so that I assume that the cleanups
> are terminated).
> 
> > > The fact that gpg has a zombie child means at least a problem with gpg.
> > 
> > A zombie is not per se a problem.  It just means that gpg has not yet
> > called the waitpid.  This may happen if a SIGINT was received while
> > reading from the keyserver helper.
> 
> This is probably what happened. But the keyserver helper terminated
> (either due to the SIGINT or because it has finished normally), so
> that waiting for reading from the keyserver helper no longer makes
> sense. Moreover a process shouldn't have a zombie child forever.
> 
> > Gpg is still a child of Mutt (I assume 5216 is the Mutt process) and
> > thus Mutt might still be reading from gpg. You should include
> > information about Mutt and best an lsof of those processes.
> 
> Concerning Mutt, the filter (pipe + fork + execl) is created by
> a mutt_create_filter_fd function which
> 1. creates a pipe;
> 2. blocks the signals (ignore SIGINT and SIGQUIT; block SIGCHLD);
> 3. does a fork;
> 4a. in the child process: unblocks the signals, closes some fd's,
>     and executes the command with execl;
> 4b. in the parent process: closes some fd's and returns.
> 
> So, when I type Ctrl-C, Mutt won't get the SIGINT because SIGINT
> is ignored (Mutt does the right thing, following the specification
> of system() in POSIX). This is normal because if the child process
> uses SIGINT for its own use, this mustn't have any effect on Mutt.
> So, Mutt keeps reading from gpg until gpg terminates in one way or
> another. But the real problem is that gpg doesn't terminate.
>