Nginx 不记录 “too many pending signals” 错误，该提示源于 Linux 内核信号队列溢出，需通过 dmesg 查看；根本解决方法是提升 RLIMIT_SIGPENDING 限制（如设为 32768）、避免高频 reload、关闭 accept_mutex 并设置 worker_shutdown_timeout 防卡死。
Nginx 本身不会记录 "too many pending signals" 这类错误，因为它不是 Nginx 自身产生的日志条目，而是 Linux 内核在进程信号队列满时向目标进程（如 nginx worker）发送信号失败时内核层面的反馈。该错误实际出现在系统级日志或 dmesg 输出中，而非 /var/log/nginx/error.log。
要真正捕捉并缓解该问题，需从信号机制、资源限制、进程行为三方面协同配置，重点不在“让 Nginx 记录它”，而在于预防它发生 + 快速定位根源。
? 如何确认是否真遇到 "too many pending signals"
运行以下命令查看实时内核消息：
dmesg -T | grep -i "pending signals"
典型输出类似：
[Sat May 2 01:30:22 2026] nginx[2345]: pending signals queue full
若出现，说明 worker 进程的 POSIX 信号队列已溢出（默认上限由 RLIMIT_SIGPENDING 控制），常见于高频率 reload、大量短连接+频繁超时触发的信号（如 SIGALRM, SIGCHLD, SIGUSR1 等）。
⚙️ 关键配置项：提升信号处理能力
调整用户级信号队列限制（必须）
Nginx worker 进程以普通用户（如 nginx 或 www-data）运行，其 sigpending 上限受 ulimit -i（即 RLIMIT_SIGPENDING）约束。
-
查看当前限制：
cat /proc/$(pgrep -f "nginx: worker")/limits | grep "pending signals"
-
永久提升（推荐值 ≥ 32768）： 在
/etc/security/limits.conf中添加：nginx soft sigpending 32768 nginx hard sigpending 32768
✅ 注意：
nginx用户名需与user nginx;配置一致；修改后需重启 systemd 或重新登录会话，且确保pam_limits.so已启用。
合理控制 reload 频率与方式
高频 nginx -s reload 是触发该问题的主因：
- 每次 reload，master 进程向所有 worker 发送
SIGUSR2（启动新 worker）和SIGQUIT（优雅退出旧 worker），同时可能伴随SIGCHLD回收。 - 若 worker 正忙于处理请求、阻塞在 I/O 或锁上，信号可能积压。
建议：
- 避免脚本循环执行
nginx -s reload - 使用配置校验前置：
nginx -t && nginx -s reload - 对接 CI/CD 时加入最小 reload 间隔（如 ≥ 30 秒）
优化 worker 行为，减少信号依赖
- 关闭非必要信号敏感功能：
# 在 events 块中禁用 accept_mutex（减少竞争，降低 SIGALRM 需求） events { accept_mutex off; multi_accept on; use epoll; } - 避免在 location 中滥用
limit_req+burst配合nodelay，这类突发流量易导致定时器密集触发。
? 补充：关联性日志增强（辅助定位）
虽然 Nginx 不记 “pending signals”，但可强化相关上下文日志，便于交叉分析：
-
在
nginx.conf的http块中开启详细错误级别（临时诊断用）：error_log /var/log/nginx/error.log debug;
⚠️ 生产环境慎用，会产生海量日志；仅用于复现问题时抓取
signal,timer,event相关 trace。 -
启用
worker_shutdown_timeout明确优雅退出窗口：worker_shutdown_timeout 10s;
防止 worker 卡死不响应
SIGQUIT，间接减少信号堆积。
✅ 总结操作清单
-
ulimit -i提升至 32768 并写入limits.conf - 检查
dmesg是否持续报pending signals - 审计自动化脚本，杜绝高频 reload
-
events { accept_mutex off; }减少信号争用 - 临时启用
error_log ... debug辅助分析（用完即关） - 设置
worker_shutdown_timeout防卡死
该问题本质是系统资源与进程模型匹配问题，不是 Nginx 配置缺陷。调优后，信号积压将显著减少，Nginx 在万级并发下的稳定性自然提升。
