Op Thu, 14 Apr 2016 20:11:48 +0200 schreef Joerg Jung <m...@umaxx.net>:
On Thu, Apr 14, 2016 at 02:00:41PM +0200, Boudewijn Dijkstra wrote:
After some hours or days after starting smtpd I get:
Apr 13 21:39:58 belisama spf[25177]: warn: filter-api:spf socketpair:
Too many open files
Apr 13 21:39:58 belisama delay[14001]: warn: session e6640a1435e43218:
write out of sequence
Apr 13 21:39:58 belisama last message repeated 95 times
After a first such warning, the same happens on every incoming message.
The filter process then has several hundred sockets to its name.
The same has also occurred with a filter chain of only filter-pause but
this didn't cause any real problems.
Oh, a few questions arise here:
1. Does it happen with filter-pause not in a chain but in a normal
single filer, as well?
I think so, but I will verify this.
2. Does your filter spf also hit the number of open files limit if you
remove the filter-pause from the chain, just running your own filter?
I don't know, and I won't verify this as long as there is a considerable
risk of data loss.
3. To which filter-process you see the open sockets, exactly
filter-pause or filter-spf?
I've seen it on both.
4. Do you think that filter-pause is the culprit or triggering filter
responsible for the hanging sessions?
No, I suspect there is a race condition or false assumption in the pipe
fitting logic.
5. Can you turn on tracing the filters and smtp session to see, where it
stuck exactly?
# smtpctl trace filter
smtpctl: invalid trace keyword: filter
# smtpctl trace filters
command succeeded
Not sure if this discrepancy should be fixed in smtpctl.c or smtpctl.8.
Anyway, I did this:
# smtpctl log verbose
# smtpctl trace smtp
# smtpctl trace filters
But the amount of information written per session to /var/log/syslog
didn't change. How should I turn on said tracing?
However, with my filter-spf in the chain this results in
messages being accepted with an empty data portion, which is highly
undesirable.
On an error, socketpair() sets errno, so as a work-around I think I
should reject with 451 if errno is found to be nonzero inside afilter
callback. Should this work?
Yes, you should check every library or syscall for it's return value
(and maybe errno) and handle the error, e.g. temporarily reject with 4xx
error code. See the existing filters for examples.
Can you confirm that an errno raised by the socketpair() call in
filter_dispatch() will be propagated to a filter callback before the
message is definitely accepted? Otherwise I will have to prevent data loss
by monitoring the open file count.
--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
