系統重啟後 Nginx reload 失效根因分析與永久修復方案

現象複現

機器重啟後，執行 nginx -s reload 無反應，錯誤日誌顯示：

2016/02/17 10:48:05 [emerg] 2298#0: open() "/data/wwwlogs/access_xxx.log" failed (24: Too many open files)

Nginx Reload 內部流程

1. 語法檢查（nginx -t）
2. 重新打開日誌檔（nginx -s reopen）
3. 重新監聽 Socket、初始化 Hash 表
4. 發送 QUIT 信號給舊 Worker 進程平滑關閉

卡在**第 2 步**打開大量日誌檔時，觸發「Too many open files」。

進程限制差異排查

根本原因：啟動順序導致限制未生效

Linux 啟動流程：

1. /etc/inittab 讀取 runlevel
2. /etc/rc.d/rc.sysinit 系統初始化
3. /etc/rc.d/rc 啟動服務腳本
4. /etc/rc.d/rc.local **最後執行**（此處啟動 Nginx）
5. /bin/login → 讀取 /etc/security/limits.conf、/etc/profile

**Nginx Master 在 login 之前啟動，故 limits.conf 尚未生效**，導致 Master 繼承系統預設 1024 限制。

三層限制配置檢查清單

永久修復：在 Nginx 啟動前手動提升限制

# /etc/rc.local
ulimit -HSn 655350   # 必須在 nginx 啟動命令之前
/usr/local/nginx/sbin/nginx

或在 Systemd 服務檔中加入：

[Service]
LimitNOFILE=655350
ExecStartPre=/bin/sh -c 'ulimit -HSn 655350'

驗證生效

# 重啟後檢查 Master 進程限制
cat /proc/$(pgrep -o nginx)/limits
# Max open files 應顯示 655350 / 655350

補充核心參數調優

# 減少 TIME_WAIT 佔用，降低核心負擔
net.ipv4.tcp_max_tw_buckets = 18000

# Nginx Hash 表擴容，應對大量虛擬主機
server_names_hash_max_size 512000;
server_names_hash_bucket_size 64;
map_hash_max_size 204800;
map_hash_bucket_size 64;

搞清啟動順序與限制繼承機制，在 rc.local 或 Systemd 中提前 ulimit，徹底解決重啟後 reload 失效。