On 2008-04-24 18:49:39 -0400, Matt Sergeant wrote:
> I think the core used to do something like this:
>
> Index: lib/Qpsmtpd.pm
> ===================================================================
> --- lib/Qpsmtpd.pm (revision 876)
> +++ lib/Qpsmtpd.pm (working copy)
> @@ -390,7 +390,10 @@
> if ($hooks->{$hook}) {
> my @r;
> for my $code (@{$hooks->{$hook}}) {
> + $SIG{ALRM} = sub { die "Alarm" };
> + my $prev = alarm(10); # should be long enough for anyone!
You haven't tried ClamAV on a 300 MHz SPARC ;-)
> eval { (@r) = $code->{code}->($self, $self-
> >transaction, @_); };
> + alarm($prev);
[...]
> But I removed it because then alarm() features VERY heavily in the
> performance profiling as an expensive system call.
Also I'm not sure that would help in Jose's case. The problem seems to
happen either while trying to read the truncated DATA line or more
likely while writing the 354 response to the data command. The first
is already protected by a (long) timeout, but the second isn't.
Jose, can you try this patch?
Index: lib/Qpsmtpd/TcpServer.pm
===================================================================
--- lib/Qpsmtpd/TcpServer.pm (revision 876)
+++ lib/Qpsmtpd/TcpServer.pm (working copy)
@@ -109,7 +111,9 @@
$self->log(LOGINFO, $line);
$buf .= "$line\r\n";
}
+ my $prev = alarm(10);
print $buf or ($self->log(LOGERROR, "Could not print [$buf]: $!"), return 0);
+ alarm($prev);
return 1;
}
Also, explicitely setting $SIG{PIPE} = 'DEFAULT' inside of the alarm
handler may help.
> A better option might be to have the parent process watch for long
> running children and terminate them.
Yup, but how long is long? If the client is trying to send a 600 MB
email that will take some time ...
hp
--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | [EMAIL PROTECTED] | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
signature.asc
Description: Digital signature
