perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Jardine <c...@cam.ac.uk>
Subject (bug report) SIGALRM problem in mod-perl causes stuck Apache processes.
Date Fri, 04 Oct 2002 14:43:25 GMT
I have recently seen a number of stuck processes on an
Apache server I run. The problem is associated with events
which appear to be attacks by the Slapper worm. The
server's OpenSSL has been upgraded, so actual penetration
by Slapper does not occur. However the stuck processes
are inconvenient, and threaten DoS.

I have analysed the problem and discovered that incorrect
manipulation of the handling of alarm signals by mod-perl
is causing some Apache timeouts to fail.

Software versions:

Solaris 8 (SPARC 64 bit)
Apache     1.3.26
perl       5.6.1
mod-perl   1.26  (source shows same problem in 1.27)
mod-ssl    2.8.10
OpenSSL    0.9.6e

The details of the problem are as follows:

If the processing of a request to the server involves any
perl handlers, mod-perl attempts to save and restore the
Apache's handler for SIGALRM. The handler is saved at line
408 of perl_config.c and restored at line 1122 of mod_perl.c.
(line numbers are from mod-perl version 1.26).

The save/restore is done using the perl utility functions
rsignal_state and rsignal.

In perl 5.6.1, rsignal sets the SA_RESTART flag regardless
of the saved state (util.c line 2509).

The original SIGALRM state is set by Apache by a call
of the libc function signal. This does leaves SA_RESTART clear.

Thus, the first use of mod-perl in the life of an Apache child
process changes the handling of SIGALRM. Thereafter, some, but
not all, Apache timeouts fail to work.

Two timeouts which I know to be affected by this are the timeout
associated with the configuration directive KeepAliveTimeout,
and that associated with the mod-ssl warning message
"mod_ssl: SSL handshake timed out".

Signal handling is greatly changed in perl 5.8. I believe that
this problem will not occur with that version of perl unless
it is compiled with PERL_OLD_SIGNALS.

I think that it is the code in perl itself which is wrong.
However, I also believe that the problem is serious enough to
warrant a maintenance release of mod-perl which programs round
the broken behaviour of rsignal in the perl versions which are
actually in use at present.

-- 
Charles Jardine - Computing Service, University of Cambridge
cj10@cam.ac.uk    Tel: +44 1223 334506, Fax: +44 1223 334679


Mime
View raw message