Gnupg interaction with speedycgi in RT 3.8.1

Hi,

I’ve noticed that unless Gnupg is disabled, the speedycgi handler
terminates after 1 (or sometimes more) requests. When it does, the
client gets a 500 response back. This is using my experimental Debian
packages on Debian etch, but I can’t imagine that the packages are doing
anything particular odd that would cause this.

I haven’t done any deep digging yet, but has anyone already seen this
problem? I can’t believe I’m doing anything that unusual in this
regard.

Bizzarely, I sometimes get the expected output in the Apache error log
(HTTP headers, then what looks like a well-formed HTML document), and
sometimes all I get is the standard "Premature end of script headers"
message.

Does this sound familiar to anyone?

Cheers,
Dominic.

Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford

Hi,

I’ve noticed that unless Gnupg is disabled, the speedycgi handler
terminates after 1 (or sometimes more) requests. When it does, the
client gets a 500 response back. This is using my experimental Debian
packages on Debian etch, but I can’t imagine that the packages are doing
anything particular odd that would cause this.

I…didn’t know anyone was still using SpeedyCGI with RT. I haven’t been
able to get it to work at all in years. What happens if you run the
SpeedyCGI script by hand and/or crank RT’s logging up to “debug”?

I…didn’t know anyone was still using SpeedyCGI with RT. I haven’t been
able to get it to work at all in years. What happens if you run the
SpeedyCGI script by hand and/or crank RT’s logging up to “debug”?

Heh. I wasn’t aware that speedycgi was marginal, or deprecated :slight_smile: Should
we be marking it as such?

speedycgi in general seems to work fine with Gnupg off.

No lines are logged to the debug log when this happens. When running by
hand I seem to reliably alternate between getting the output to STDOUT
and STDERR.

Will do a bit more prodding during daylight hours, but if it’s not really
being used these days then I might just attach a health warning to the
handler and be done with it.

Cheers,
Dominic.

Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford

I…didn’t know anyone was still using SpeedyCGI with RT. I haven’t been
able to get it to work at all in years. What happens if you run the
SpeedyCGI script by hand and/or crank RT’s logging up to “debug”?

Heh. I wasn’t aware that speedycgi was marginal, or deprecated :slight_smile: Should
we be marking it as such?

Well, if it’s otherwise working well AND in active use, I’m happy to
allow it to return to the world of the living.

We had issues with FastCGI had our redirection of STDERR/STDOUT,
prompting us to write some wrapper code. Does graphviz cause the same
issue?

Heh. I wasn’t aware that speedycgi was marginal, or deprecated :slight_smile: Should
we be marking it as such?

Well, if it’s otherwise working well AND in active use, I’m happy to
allow it to return to the world of the living.

We had issues with FastCGI had our redirection of STDERR/STDOUT,
prompting us to write some wrapper code. Does graphviz cause the same
issue?

No, graphviz works fine with gnupg off.
I can easily imagine that gnupg tickles some file descriptor bug
somewhere though.

Attached is an strace showing the sequence of events in the backend,
resulting in the output going to STDERR rather than STDOUT, including an
exec of gnupg (note; does this mean that every request will hit exec gpg?)

Presumably the backend receiving EPIPE when writing the output is going
to be related, but I can’t quite follow the strace well enough to see
why. If anyone else fancies digging a bit deeper, feel free :slight_smile:

Dominic.

Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford

strace (27.1 KB)

I can easily imagine that gnupg tickles some file descriptor bug
somewhere though.

Attached is an strace showing the sequence of events in the backend,
resulting in the output going to STDERR rather than STDOUT, including an
exec of gnupg (note; does this mean that every request will hit exec gpg?)

Presumably the backend receiving EPIPE when writing the output is going
to be related, but I can’t quite follow the strace well enough to see
why. If anyone else fancies digging a bit deeper, feel free :slight_smile:

Sounds like Mail::GnuPG 0.15 might fix this. Earlier versions had
significant problems in the interaction with the gpg process, including
deadlocks and unexpected SIGPIPEs.

http://bugs.debian.org/412041

http://bugs.debian.org/459693

Niko Tyni ntyni@debian.org

I can easily imagine that gnupg tickles some file descriptor bug
somewhere though.

Attached is an strace showing the sequence of events in the backend,
resulting in the output going to STDERR rather than STDOUT, including an
exec of gnupg (note; does this mean that every request will hit exec gpg?)

Presumably the backend receiving EPIPE when writing the output is going
to be related, but I can’t quite follow the strace well enough to see
why. If anyone else fancies digging a bit deeper, feel free :slight_smile:

Sounds like Mail::GnuPG 0.15 might fix this. Earlier versions had
significant problems in the interaction with the gpg process, including
deadlocks and unexpected SIGPIPEs.
However Mail::GnuPG is not used in new implementation of RT’s gpg
interaction, but it’s 100% about sig handlers or std{in, out, err}.

http://bugs.debian.org/412041

http://bugs.debian.org/459693


Niko Tyni ntyni@debian.org


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

I can easily imagine that gnupg tickles some file descriptor bug
somewhere though.

Attached is an strace showing the sequence of events in the backend,
resulting in the output going to STDERR rather than STDOUT, including an
exec of gnupg (note; does this mean that every request will hit exec gpg?)

Presumably the backend receiving EPIPE when writing the output is going
to be related, but I can’t quite follow the strace well enough to see
why. If anyone else fancies digging a bit deeper, feel free :slight_smile:

Sounds like Mail::GnuPG 0.15 might fix this. Earlier versions had
significant problems in the interaction with the gpg process, including
deadlocks and unexpected SIGPIPEs.

However Mail::GnuPG is not used in new implementation of RT’s gpg
interaction, but it’s 100% about sig handlers or std{in, out, err}.

Right, sorry for my confusion.

As penance, I actually looked into this. It’s a bug in
SpeedyCGI, triggered by the FastCGI filehandle wrapping code in
RT::Util::safe_run_child(). See http://bugs.debian.org/506957 for a
minimal test script.

A workaround would be

diff --git a/lib/RT/Util.pm b/lib/RT/Util.pm
index 544618b…bf6eb2d 100644
— a/lib/RT/Util.pm
+++ b/lib/RT/Util.pm
@@ -56,7 +56,7 @@ our @EXPORT = qw/safe_run_child/;
sub safe_run_child (&) {
local @ENV{ ‘LANG’, ‘LC_ALL’ } = ( ‘C’, ‘C’ );

  • return shift->() if $ENV{‘MOD_PERL’};
  • return shift->() if $ENV{‘MOD_PERL’} || $CGI::SpeedyCGI::i_am_speedy;

    We need to reopen stdout temporarily, because in FCGI

    environment, stdout is tied to FCGI::Stream, and the child

which fixes the immediate problem for me. I haven’t tested actually
using the gpg support with this, though. Dominic, can you do that easily?

I should probably mention that I’m the one to blame for keeping SpeedyCGI
alive in this context. The project has been inactive since 2003, and I’ve
patched the Debian speedy-cgi-perl package for the Perl 5.10 and Apache 2.2
transitions.

I still like the way it gives persistent perl script speedups with
minimal or no web server configuration.
Niko Tyni ntyni@debian.org

I should probably mention that I’m the one to blame for keeping SpeedyCGI
alive in this context. The project has been inactive since 2003, and I’ve
patched the Debian speedy-cgi-perl package for the Perl 5.10 and Apache 2.2
transitions.

I still like the way it gives persistent perl script speedups with
minimal or no web server configuration.

If someone with at least minimal interest in RT is keeping SpeedyCGI
running, I’m willing to keep shipping it :wink:

For now, I’ve applied the patch to trunk (r17044) as it makes sense :wink:

Thanks!