【发布时间】:2018-01-18 11:03:00
【问题描述】:
我已经实现了一个运行良好的基本 SMTPServer,但我遇到了一个问题,我不知道如何解决它。
检查为运行我的脚本 (ls -l /proc/$PID/fd/ | grep "socket:" | wc -l) 的进程的 $PID 打开的文件描述符时,文件描述符的数量不断增加。
由于我是通过“socket:”过滤的,这显然是一些套接字保持打开状态,当然是因为某些邮件提供商没有明确退出。
我已经在本地测试了一些连接到那个SMTPServer代码的Python脚本,即使我不关闭连接,当客户端进程停止时,客户端关闭连接,文件描述符被删除。
我考虑过实现等待超时,或者每 N 个连接重新启动进程,但这些只是针对更大问题的坏补丁。
你知道那是从哪里来的吗?
有关信息,我的 process_message 包装器被包围了
try:
# ...
except:
return '450 Please try again later"
所以来自我的代码的异常应该得到很好的处理。
这是我的代码(简化):
class MyMXServer(SMTPServer):
def __init__(self, host='127.0.0.1', port=25):
self.srs = SRS.new(os.getenv('SRS_KEY', 'some passwd'))
return SMTPServer.__init__(self, (host, port), None)
def process_message(self, greeting, peer, mailfrom, recipients, data, **kwargs):
try:
return self._process_message(greeting, peer, mailfrom, recipients, data, **kwargs)
except:
logging.getLogger('err').exception('[EXCEPTION]')
return '450 Please try again later.'
def _process_message(self, greeting, peer, mailfrom, recipients, data, **kwargs):
# Various things like checking DNSBL, SPF, Spam, etc
【问题讨论】:
-
您是否可以控制客户端,或者您是否接受来自整个大坏网的连接?一些客户端可能会因为马虎或更糟而使连接挂起。
-
在其他新闻中,将有一个关于使用
grep -c代替grep | wc -l的研讨会。
标签: python sockets smtplib asyncore