On Mon, 5 Mar 2007, Charlie Brady wrote:
On Mon, 5 Mar 2007, Ask Bj?rn Hansen wrote:
On Mar 5, 2007, at 11:23 AM, ampster wrote:
> I have created a bug entry for SMESERVER which uses qpsmtpd.
> I think the bug is related to this issue and I have attached a logfile
> extract and a wireshark trace.
Yeah, this is a pretty bad bug - whatever it is (at least the most
annoying we've had in years...). I noticed it too on one of my mail
servers when the spamassassin server was unavailable in a particular way
(network being down IIRC). I couldn't make it happen again though, so I
didn't get anywhere debugging it.
alarm $timeout;
while (<STDIN>) {
alarm 0;
$_ =~ s/\r?\n$//s; # advanced chomp
$self->log(LOGDEBUG, "dispatching $_");
$self->connection->notes('original_string', $_);
defined $self->dispatch(split / +/, $_)
or $self->respond(502, "command unrecognized: '$_'");
alarm $timeout;
}
alarm(0);
Note that there is no alarm set around calls to dispatch(). If any hook takes
infinite time then it looks like a connection will stall forever, even if the
socket has been closed by the peer.
I don't think this "pretty serious bug" has yet had any attention. This
has come to my attention since clamav-0.90.1 has some locking bugs (and
perhaps some other bugs when out of memory*) which cause it to stall,
which pretty soon leads to all qpsmtp connection slots being full with
connections waiting for clamdscan to terminate.
Is there any reason that the same alarm couldn't just be set around
dispatch() as is set around <STDIN>?
* http://www.contribs.org/bugzilla/show_bug.cgi?id=2743
