OK after some digging I have some additional infos for anyone that may
be willing to spend some time on it:
* Important context: we're running dbmail-lmtpd from inetd in order to
avoid some memory leaks we faced with LMTPD in the past (we handle a lot
of mails) and some database congestions we faced as well.
* The problem is clearly stated in the source of the file clientbase.c
at line 423 where a comments says "EOF on stdin is not an error". Well,
an EOF surely is not an error, but when a connection is dropped INETD
sends an EOF (and a SIGHUP) to the forked process to notify him that the
client has gone. LMTPD on the contrary thinks he has to wait for
something else to happen (I wonder what) and get stuck in an infinite
loop where the function client_session_read (from clientsession.c)
around line 245 keeps on callng ci_read_cb pretending it to read from a
I think there are a couple of different way of dealing with the problem:
* having client base return EOF if there's an EOF even if we're on
STDIN. I wonder if that may break things like dbmail-deliver that may
read a bunch of files at once.
* injecting the timeout handling code from EV_TIMEOUT that is
misteriosly missing inside client_session_read ... that won't fix the
problem but at least it would avoid lmtpd to get stuck there for ever.
Truth to be told, since the "problem" lies in the shared codebase among
the daemons I think I already faced the same problem in the past when I
tried to run IMAP behind INETD.
Closing notes, I installed timelimit and placed it between inetd and
lmtpd. It now kills any lmtpd that has been running longer than 120
If anyone is willing to spend some time for a better fix I'd be glad to
Chief Technology Officier
ROMA - FI - PA
Società del Gruppo OVIDIO TECH S.R.L.
On 2017-09-08 12:20, Andrea Brancatelli wrote: > Hello everybody
> after a long time I've been able to track down a problem with DBMAIL LMTPD going 100% from time to time.
> I understood quite soon that it depended on some badly formatted mail...
> Anyhow, I was finally able to spend some time on it and track out a log for the problem.
> Here it is... Maybe someone can get a clue about what is the problem...
> Andrea Brancatelli
> Schema31 S.p.a.
> Chief Technology Officier
> ROMA - FI - PA
> Tel: +39.06.98.358.472
> Cell: +39.331.2488468
> Fax: +39.055.71.880.466
> Società del Gruppo OVIDIO TECH S.R.L.
> DBmail mailing list