Scrapy爬虫间歇性出现getrandom()初始化失败问题求助

我来帮你梳理下这个偶发问题的排查方向和落地测试步骤——这类所有爬虫同时出相同错误、重启supervisord就恢复的情况，大概率和进程资源泄漏或依赖库的长期运行兼容性有关，毕竟Scrapy 1.4是比较早期的版本了。

一、先锁定依赖版本的兼容性问题 #

Scrapy 1.4对pyOpenSSL、cryptography这些SSL相关库有版本要求，旧版本的库在长时间运行的进程里容易出现上下文失效或连接泄漏：

• 先查当前环境的依赖版本，执行命令：

  pip list | grep -E "(pyOpenSSL|cryptography|urllib3|Scrapy)"
  

• 对比Scrapy 1.4官方的依赖要求（pyOpenSSL>=0.14，cryptography>=1.4），如果你的版本太旧（比如pyOpenSSL<16.0），可以尝试升级到该版本兼容的最高稳定版（比如pyOpenSSL<=17.5.0），旧版本的SSL库确实存在线程安全和连接池泄漏的已知问题。

二、排查django-rq worker的进程生命周期 #

supervisord管理的worker如果长时间不重启，很容易积累资源泄漏（比如SSL连接句柄、内存碎片）：

• 给django-rq worker加上--max-jobs参数，比如设置成--max-jobs 100，让worker处理100个任务后自动退出，supervisord会自动拉起新的worker，避免进程长期运行导致的资源耗尽。
• 检查supervisord配置里worker的autorestart是否设为true，确保进程异常退出时能自动重启，避免单点故障。

三、增强日志捕获错误详情 #

因为无法主动复现，必须把OpenSSL的错误栈完整记录下来：

• 在Scrapy的settings.py里开启DEBUG级日志：

  LOG_LEVEL = 'DEBUG'
  LOG_FILE = '/var/log/scrapy/debug.log'
  

• 在django-rq的worker启动命令里加上日志参数，或者在爬虫的异常处理中专门捕获OpenSSL.SSL.Error，打印完整traceback：

  from OpenSSL import SSL
  
  try:
      # 爬虫核心逻辑
  except SSL.Error as e:
      import traceback
      self.logger.error(f"OpenSSL错误详情: {traceback.format_exc()}")
  

• 同时监控Redis的连接状态，用redis-cli info clients查看连接数是否异常增长，判断是否有连接泄漏。

四、模拟长期运行的测试场景 #

手动模拟持续触发爬虫的场景，观察是否能复现问题：

• 写一个简单的测试脚本，循环调用django-rq的任务接口，持续触发爬虫；
• 同时监控worker进程的资源使用：
  • 用lsof -p <worker-pid>查看文件句柄数是否持续增长；
  • 用top -p <worker-pid>观察内存占用是否不断升高；
• 如果在持续运行几小时后出现OpenSSL错误，基本可以确定是资源泄漏问题。

五、检查系统级SSL配置（兜底排查） #

虽然重启supervisord就恢复，系统级问题概率低，但可以快速排查：

• 检查系统CA证书目录/etc/ssl/certs是否完整，有没有证书过期的情况；
• 查看最近的系统更新记录，是否有OpenSSL库的更新导致兼容性问题。

临时缓解方案 #

如果暂时找不到根源，可以先配置supervisord定时重启worker，比如每天凌晨重启一次，避免进程长期运行积累问题：

# supervisord配置示例
[program:django-rq-worker]
command=python manage.py rqworker default
autorestart=true
startretries=3
user=www-data
stdout_logfile=/var/log/rq-worker.log
stderr_logfile=/var/log/rq-worker-error.log
# 每天凌晨2点重启
stopsignal=TERM
stopwaitsecs=60
startsecs=10
directory=/path/to/your/django/project

内容的提问来源于stack exchange，提问作者mouch