我们有一个运行很长时间的进程(Rake 任务)，它使用 Faraday 和 net_http_persistent 适配器向远程主机发出 HTTPS 请求。在几个小时到几天的运行时间后，它会停止发出请求。
该进程还使用 Excon 发出一些请求(向我们的异常报告服务报告异常)，并且两个 HTTP 客户端都记录了相同的错误，只是措辞略有不同。这两个错误是:
Faraday::SSLError: SSL_connect SYSCALL returned=5 errno=0 state=error: certificate verify failed
Excon::Error::Certificate: SSL_connect SYSCALL returned=5 errno=0 state=error: certificate verify failed (OpenSSL::SSL::SSLError) Unable to verify certificate. This may be an issue with the remote host or with Excon. Excon has certificates bundled, but these can be customized:
我们的异常报告服务未能接收到任何这些异常。所以我们只在日志中发现了这些错误。
最佳答案
为了重现这个问题，我运行了一个 Faraday 请求循环，直到它失败。我发现虽然引发的异常是 Faraday::SSLError，但一旦我尝试在 REPL 中执行任何其他需要打开文件的操作，它就会引发 Errno::EMFILE : 打开的文件太多。
我终于明白了。红色鲱鱼是由 OpenSSL 库捕获 EMFILE 系统错误引起的，而不是引发一般 SSL 连接失败。 Faraday 和 Excon(由异常报告工具使用)都这样做，因此无法看到真正的问题。
根本问题是该进程已达到打开文件的限制。这是由 the way that net-http-persistent keeps connections open until instructed to shut down 引起的结合 Faraday has no mechanism to instruct its adapter to shut down 的事实.
解决方案是从 net-http-persistent 切换到 Excon，它支持持久连接，只要它被配置为这样做:
Faraday.new(url: url) do |faraday|
faraday.adapter :excon, persistent: true
end
关于ruby - Faraday with net-http-persistent 使连接保持打开状态，导致 "Errno::EMFILE: Too many open files"，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57213115/