I searched a little bit and it seems that there can be problems with signal handling in mod_perl under certain circumstances (though I never had problems yet myself).
See http://search.cpan.org/dist/mod_perl/docs/user/coding/coding.pod#Using_Signal_Handlers Essentially - signals wont work in a threaded mpm (shouldnt matter for you since you are using apache 1.3), - you should use the POSIX-signals (see link above for an example), - signals can conflict with apache signals (apache 1.3 uses alarm for i/o operations - but if you dont do a read/write inside your eval, that shouldnt be a problem). Also keep in mind that there can be other reasons why a code is working when executed in a shell but isnt in mod_perl. Among others the DBD may behave differently because of different ENV-vars. Hendrik Am Di, 2.12.2008, 22:30, schrieb April Papajohn (Blumenstiel): > On Tue, Dec 2, 2008 at 2:19 PM, Hendrik Schumacher <[EMAIL PROTECTED]> > wrote: >> alarm() definitely works in mod_perl. > > Then I wonder why my test code is successfully interrupting the > DBI->connect method from the command line, but not when running in > modperl 1.3 (the versions of perl are the same). > > sub handler { > > ... > > > eval { > > > my $h = set_sig_handler('ALRM',sub {die "DBD took longer than > $MYSQL_ALARM_LIMIT seconds to do its MySQL work\n"}); > > alarm($MYSQL_ALARM_LIMIT); > > my $dbh = DBI->connect($datasource,'','', {PrintError => 0}); > > if (!$dbh) { > warn $DBI::errstr; > } else { > > my $data = rand(); > > > my $sh2 = $dbh->prepare("select * from test where data = $data "); > > $sh2->execute; > > my @result = $sh2->fetchrow_array; > > warn "Result fetched: @result\n"; > > > } > > }; > alarm(0); > > ... >
