June 11, 2024 6:38 PM, "Kirill A. Korinsky" <[email protected]> wrote:
> misc@, > > I just discovered that smtpd dies becuase of filter hit "too many open > files". > > Last logs from smtpd: > > Jun 11 13:06:03 mx1 smtpd[80363]: 1825a196e20867b3 mta disconnected > reason=quit messages=1 > Jun 11 13:07:06 mx1 smtpd[80363]: 1825a197ad6634d4 smtp connected > address=198.2.134.32 > host=mail134-32.atl141.mandrillapp.com > Jun 11 13:07:08 mx1 smtpd[80363]: 1825a197ad6634d4 smtp tls > ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256 > Jun 11 13:07:08 mx1 smtpd[82182]: auth: 1825a197ad6634d4 Can't open tempfile: > Too many open files > Jun 11 13:07:08 mx1 smtpd[80363]: dispatcher: tree_xpop(0xfae2ce35960, > 0x1825a197ad6634d4) > Jun 11 13:07:08 mx1 smtpd[61396]: smtpd: process dispatcher socket closed > > [...] > > I expect that it clsoes connection, but not kills smtpd. > > Am I wrong? > I'm unsure what the filter really did and it is a bit harsh to read, but the rules are as follow: 1- filters are allowed to fail as long as they do so properly 2- filters are not allowed to misbehave If Too many open files is handled properly, you fall into 1- and it should translate to a session close. If it's not handled properly and smtpd detects any problem with the filter then it'll abort because it won't run with a buggy filter. I may be wrong about your bug but with just a quick glance I saw mem leaks and the error message you have seems to imply a leak of descriptor as well so I'd be tempted to assume that the filter is misbehaving and that it did not report the fd exhaustion properly to smtpd leading to termination. How I'd go about debugging that: - figuring out why smtpd detects misbehaviour, maybe with tracing filters, in my experience its often a print of an error message on the wrong fd. - when this is understood, tracking the leak and fixing it. Cheers, Gilles
