Peter J. Holzer escribió:
[...]
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;
}
I'll try the patch as soon as I can, but I'm not all that optimistic
about it... I'll explainy why:
It seems that DBI at destruction time is doing something bad... but I
can't trace the code down to what it's doing, and why only when TLS
session is active, and only (until another pattern is detected) when a
"DATA" without line terminator is issued and connection is closed.
It looks like a corner, corner, corner case, but maybe it can be
reproduced in other ways...
Also, explicitely setting $SIG{PIPE} = 'DEFAULT' inside of the alarm
handler may help.
Perl's default SIG_PIPE behaviour is to eat the signal (if I'm not
remembering badly). But I get the message... exit on SIG_PIPE...
The bad thing is that I don't know where to establish that signal
handler, and if it would cause major pain to other plugins :S, because
everything seems to happen out of plugin handlers...
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 ...
How long is long for a plugin handler? how long is long for a session?
Different plugins will want different timeout times, and some plugins
won't want timeout...
I think that plugin timeouts, if necessary, have to be very well thought
and discussed... And if they will hurt performance, just to get
"badly" designed plugins to timeout, maybe they are not necessary. For
badly, I'm referring to plugins that will not timeout by themselves.
Thanks for all the replies.
Has anyone had the oportunity to reproduce the bug?
Jose Luis Martinez
CAPSiDE
[EMAIL PROTECTED]
