Sahil Tandon:
> Dec 14 02:00:13 mx0 postfix/smtp[52172]: 82A9D8FC0A:
> to=<r...@example.org>, relay=internal.example.org[ip_address]:25,
> delay=1.8, delays=0.66/0/0/1.1, dsn=2.0.0, status=sent (250 2.0.0 Ok:
> queued as 47E9B1065670)
> Dec 14 02:00:18 mx0 postfix/smtp[52172]: warning: problem talking to
> service private/scache: Operation timed out
> Dec 14 02:00:25 mx0 postfix/smtp[52172]: warning: problem talking to
> service private/scache: Operation timed out
> Dec 14 02:00:25 mx0 postfix/smtp[52172]: warning: disabling connection
> caching
The default connection_cache_protocol_timeout setting is 5 seconds,
which explains the time between the first attempts. There is an
extra 1-second delay between retry attempts, which explains the
longer time between the second attempt and giving up. So the
connection cache client side seems to work as intended.
Most of the information sent over the protocol is of the same kind
that Postfix sends between daemons all the time: domain names, IP
addresses, and numbers.
The only distinguishing property of the protocol is that it also
sends file descriptors, just like postscreen->smtpd does (and
postscreen->tlsproxy).
And indeed I recall that I ran into a bizarre bug with FreeBSD 7.1
file descriptor passing, as I was developing the first versions of
postscreen in 2009.
This comment is from postscreen:
/*
* Closing the smtp_client_fd here triggers a FreeBSD 7.1 kernel bug
* where smtp-source sometimes sees the connection being closed after
* it has already received the real SMTP server's 220 greeting!
*/
This is about closing the remote SMTP client socket in postscreen,
after postscreen had made the kernel request to send that socket
to smtpd. The postscreen workaround was to wait until the smtpd
process closes the file descriptor over which the remote SMTP client
socket was received, before closing the remote SMTP client socket
in postscreen. It's 2.5 years later now, and I do not recall if
this happened on my uniprocessor laptop or on my multiprocessor
workstation.
In the scache client, the file descriptor sending operation is
always preceeded and followed by a data read. For this reason we
can't be triggering the same bug that postscreen triggered, but
maybe there is another bug in FreeBSD file descriptor passing code.
Wietse
