Hi,
Michael Fischer v. Mollard <lists@???> (Sa 19 Mär 2016 19:41:39 CET):
> Hello,
>
> I've a strange problem with the connection timeout on an Exim 4.86:
>
> > 2016-03-18 12:19:57 1agsRh-0001EC-8a <= XXX@XXX H=XXX [XXX] P=esmtps
> > X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256 CV=no S=13566 id=XXX
> > 2016-03-18 13:12:36 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 13:54:35 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 14:49:12 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 14:50:11 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 16:13:30 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 16:44:28 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 16:49:12 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 16:49:27 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 17:20:58 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 17:29:36 1agsRh-0001EC-8a Spool file is locked (another
> > process is handling this message)
> > 2016-03-18 17:43:20 1agsRh-0001EC-8a SMTP error from remote mail
> > server after end of data: 421 XXX Service not available - SIGTERM or
> > SIGINT received - closing connection.
>
> Ignoring that the strange behavior of the receiving side (I explicitly
> killed the client, so it closed the connection as seen in the logs) I'd
> expect that the sending exim quit the connection after final_timeout
> (not explicitly given, so it should be 10 minutes). Is there an
> explanation why the sending exim is not closing the connection? Could
> this be a regression as I've never seen that before?
I do not see any indication that some process is exceeding it's timeout.
The only thing I see is, that a process (probably the queue runner)
can't lock the spool file, because it's locked already. The last log
line shows a forceful closed connection, but we've no idea if this is
the same process as started just after the messages came in.
You may add the +pid log_selector to get an idea about the processes
(not) handling a message.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
