Gunicorn进程因signal 1、signal 9、signal TERM等信号终止的原因及调试方法

报错日志 #

[2021-10-06 05:29:36 +0700] [497750] [WARNING] Worker with pid 497759 was terminated due to signal 1

问题1：signal 1的触发原因 #

signal 1对应Linux系统的SIGHUP信号，你已经排查过CPU、内存资源充足，可从以下场景排查：

• 若你直接在SSH会话前台启动gunicorn，未使用nohup后台运行也没有用进程管理工具托管，SSH连接断开时，操作系统会给该会话下所有关联进程发送SIGHUP信号
• 若你使用supervisord、systemd等进程管理工具托管gunicorn，工具执行配置重载、服务重启操作时，会默认给gunicorn主进程发SIGHUP，主进程收到信号后会给所有子worker转发SIGHUP触发worker重载
• 极少数场景下是其他进程调用kill系统调用误发信号

问题2：signal TERM的触发原因 #

signal TERM对应Linux系统的SIGTERM信号，属于通用进程终止信号，并非只有手动关闭gunicorn才会触发，常见触发场景：

• 进程管理工具（supervisord、systemd、K8s等）执行服务停止、重启、实例缩容操作时，会优先发送SIGTERM通知进程优雅退出，超时未退出才会发送signal 9（SIGKILL）强制终止
• 操作系统触发关机、重启流程时，init进程会先给所有用户进程发送SIGTERM通知退出
• 自动扩缩容脚本、定时任务等逻辑如果存在匹配gunicorn进程名终止进程的规则，默认也会发送SIGTERM

问题3：信号问题调试方法 #

可以通过以下方式查询信号触发时间和来源：

• gunicorn自带的日志已经记录了信号触发的大致时间，即报错日志开头的时间戳字段，你可以把gunicorn日志级别调整为debug，获取更多主进程与worker的交互细节
• 部署auditd审计工具监控信号发送行为：
  1. 安装auditd后添加监控规则：auditctl -a exit,always -F arch=b64 -S kill -k signal_monitor
  2. 所有kill系统调用都会被记录到/var/log/audit/audit.log中，日志包含信号发送方PID、进程名、接收方PID、信号类型、精确触发时间
• 你可以在应用代码中自定义信号处理钩子，收到SIGHUP、SIGTERM等信号时，主动将当前时间、调用栈、进程上下文信息写入自定义日志，方便回溯问题

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