On Thu, Nov 14, 2024 at 02:13:11PM -0600, Matt Saladna via Postfix-users wrote:
> In situations where either a server has run out of storage, a btree database
> can become corrupted. I see this evidenced in the following manner,
> specifically "no cursor":
>
> Nov 14 20:10:44 web2 postfix/postscreen[1377623]: warning: dict_proxy_lookup:
> service proxywrite: Connection reset by peer
> Nov 14 20:10:44 web2 postfix/master[2514]: warning: process
> /usr/libexec/postfix/proxymap pid 1378868 killed by signal 6
> Nov 14 20:10:45 web2 postfix/proxymap[1378875]: panic: dict_db_sequence: no
> cursor
>
> Postfix version: 3.7.11
> libdb: 5.3.28-42.el8_4
> smtpd_tls_session_cache_database = proxy:btree:$data_directory/smtpd_scache
You rarely need writable Berkeley DB databases that can grow very big.
In this particular case you have chosen to implement a server-side TLS
session cache, but this is long ago obsoleted by TLS session tickets.
Best practice is to leave smtpd_tls_session_cache_database at its
default empty value. Perhaps we should at some remove support for
server-side TLS session caches. If the client does not support session
tickets, it probably does not reuse server side sessions at all, or very
effectively.
The client-side TLS session is however useful, and should not grow
unreasonably, because it is keyed by the hostnames of machines to which
you send outgoing mail. Spammers generally don't get to choose which
domains you send mail to, so this cache remains much smaller. You
can also, if needed reduce the cache TTL from ~1h to say 15m if the
cache is still large.
Yes, of course, as a matter of principle you want databases that recover
from temporary space exhaustion. Perhaps LMDB will exhibit better
behaviour when disk space is temporarily tight, and subsequently
recovers. You'd have to test that.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
