(bug report) SIGALRM problem in mod-perl causes stuck Apache processes.
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-ssl2.8.10 OpenSSL0.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 [EMAIL PROTECTED]Tel: +44 1223 334506, Fax: +44 1223 334679
Perl 5.7.3 breaks mod_perl tied handles [PATCH]
I have been testing my mod_perl-1.26 applications under perl 5.7.3.
I have discovered that the tying of STDIN and STDOUT does not work.
This is caused by a change in the internals of the implementation
of tied handles in Perl. The following extract from the source
of Perl (pp_sys.c ll 764 ff) describes the change
methname = "TIEHANDLE";
how = PERL_MAGIC_tiedscalar;
/* For tied filehandles, we apply tiedscalar magic to the IO
slot of the GP rather than the GV itself. AMS 20010812 */
if (!GvIOp(varsv))
GvIOp(varsv) = newIO();
varsv = (SV *)GvIOp(varsv);
break;
I have got myself going by patching mod_perl as below. This
patch makes mod_perl work with 5.7.3, but, of course, stops it
working with 5.6.x. It is beyond my knowledge to make this patch
version dependent, as it needs to be.
*** /tmp/sccs.I.aOiqMon Mar 18 14:41:11 2002
--- perlio.cMon Mar 18 12:18:22 2002
***
*** 54,61
#define TIEHANDLE(name,obj) \
{ \
dHANDLE(name); \
! sv_unmagic((SV*)handle, 'q'); \
! sv_magic((SV*)handle, obj, 'q', Nullch, 0); \
}
#if 0
--- 54,61
#define TIEHANDLE(name,obj) \
{ \
dHANDLE(name); \
! sv_unmagic((SV*)GvIOp((SV*)handle), 'q'); \
! sv_magic((SV*)GvIOp((SV*)handle), obj, 'q', Nullch, 0); \
}
#if 0
--
Charles Jardine - Computing Service, University of Cambridge
[EMAIL PROTECTED]Tel: +44 1223 334506, Fax: +44 1223 334679
