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 
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 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 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
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
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
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’};
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 
For now, I’ve applied the patch to trunk (r17044) as it makes sense
Thanks!