1 篇博文 含有标签「日志轮转」

cPanel 服务器每天 ~20:08 轮转域名日志（domlog）后，新日志文件持续 0 字节：访问日志证据面静默变盲，反爬/安全规则全部失明——而面板上一切显示正常。

在为客户执行 行业龙头制造企业中国全托管 项目时遇到此问题——在阿里云中国区从零搭建并长期运维 cPanel/WHM 托管环境，本文记录这个断流坑的两层根因与根治。

TL;DR​

两层根因叠加：cPanel 的 domlog 轮转机制本身不 reload apache；而防断流的兜底 cron 又恰好写错了命令——每晚空跑。

• 立即恢复：apachectl graceful，domlog 秒级恢复写入
• 根治：轮转后双行 cron——apachectl graceful（恢复写入）+ fail2ban-client -q reload（jail 重挂新日志文件）
• 判据：ls -la /etc/apache2/logs/domlogs/<域名>-ssl_log，轮转 1 小时后仍 0 字节即中招

问题现象​

每日轮转（本机 ~20:08）后，站点日志（domlogs/<域名>-ssl_log）持续 0 字节数小时：

• 09-27 首次实证：轮转后新文件 0 字节，直到人工介入
• 09-28 复现：20:07 轮转，21:08 仍 0 字节——此前布的兜底 cron 没有起作用

断流的危害在「静默」：日志不报错、面板无告警，但 fail2ban、流量分析、入侵检测全部失去数据源。对托管环境来说，这是证据面的无声塌方。

排查：轮转窗口的 journalctl 是分水岭​

第一步：确认断流窗口内 apache 的动作。

journalctl -u httpd --since "20:00" --until "21:30"

结果是零动作——轮转前后 apache 没有任何 reload/restart 记录。这直接定位了断流机制：轮转程序挪走了旧文件、创建了新文件，但 apache 从未被通知「重新打开日志文件」。

第二步：检查兜底 cron 为什么没兜住。 轮转窗口内 apache 零动作，那防断流 cron（每晚 21:00）呢？手动执行 cron 里的命令，当场暴露：

$ fail2ban-client reload -q
ERROR  No section: '-q'

两个错误同时现形：

1. 语法错：-q 是 fail2ban-client 的全局选项，必须放在子命令前面（fail2ban-client -q reload）；写在 reload 后面被当成 jail 名解析，直接报错退出
2. 对象错：就算语法对了，fail2ban-client reload 重载的是 fail2ban 自己——它不恢复 apache 的日志写入。真正的断流点在 apache，需要的是 apachectl graceful

也就是说：这个兜底 cron 从部署那天起，每晚都在「执行一条必然报错的命令」，从未起过作用，也没有任何告警——09-28 晚断流照常复现，就是它空跑的直接后果。

根因：轮转机制不 reload，兜底又写错对象​

把两层根因分开看：

根因一：cPanel domlog 轮转不 reload apache。 轮转动作 = 挪走旧文件 + 创建新文件，仅此而已。而 apache 对日志文件的写法是打开一次、持有文件描述符持续写——它持有的描述符指向旧文件的 inode，轮转移走旧文件后，写入跟着旧 inode 走进归档，新文件从创建起就无人写入。这是文件描述符语义决定的，不是故障，是机制——所以必须由外部在轮转后通知 apache 重开文件（reload）。

根因二：兜底 cron 的命令双重写错。 布兜底时的意图是对的（轮转后 reload 一遍），但命令写成了 fail2ban-client reload -q：既把 -q 放错位置导致语法报错，又选错了 reload 对象（fail2ban 管 jail，不管 apache 日志句柄）。两层错误叠加的结果是兜底完全空转，且无任何告警——cron 报错不通知人，这是第二个静默点。

修复：双行 cron，各管一件事​

重写兜底 cron（/etc/cron.d/ 下自建文件），拆成两行、各司其职：

# 每晚 21:00 恢复 domlog 写入（轮转 ~20:08 之后）
0 21 * * * root /usr/sbin/apachectl graceful
# 每晚 21:05 让 fail2ban 重挂新日志文件（-q 是全局选项，必须放子命令前）
5 21 * * * root /usr/bin/fail2ban-client -q reload

设计考虑：

• 21:00 graceful：在轮转（~20:08）之后、且在日志消费高峰前，恢复 apache 对新文件的写入
• 21:05 fail2ban reload：与 graceful 分开 5 分钟——fail2ban 监控的日志路径在轮转后指向新文件，需要 reload 让 jail 重新挂载；错开是为了不和 apache reload 抢资源
• 手工验证（当晚）：graceful 后 domlog 恢复写入（922 字节起步），fail2ban-client -q reload 正常返回

这台机器装机阶段的另外几类坑（TFA、资源 404、域名挂载）已在 AlmaLinux 10 装 cPanel：TFA 不生效、资源 404、域名挂载被拒 一文拆解，可与本篇拼出完整的 cPanel 新机排障图。

常见问题​

cPanel domlog 轮转后新文件 0 字节怎么办？​

手工 apachectl graceful 立即恢复写入；根治是在轮转后加一行 cron（如每晚 21:00）做 graceful。根因是 cPanel 轮转机制本身不 reload apache——apache 继续写旧 inode，新文件无人接管。判据：ls -la 查 domlogs 下站点日志，轮转 1 小时后仍 0 字节即中招。

apache 日志文件轮转后内容去哪了？​

旧内容在轮转归档里；「新文件是空的」的成因是 apache 的文件描述符还挂在旧 inode 上继续写，新文件没人写。graceful reload 让 apache 重开日志文件句柄（切到新 inode），写入才恢复——这就是轮转后必须 reload 的原因。

crontab 定时任务没执行怎么排查？​

三步：crontab -l 确认任务存在；把命令手动跑一遍看真实报错（本例 fail2ban-client reload -q 手跑即暴露 ERROR No section: '-q'——-q 是全局选项必须放子命令前）；再查 cron 日志确认触发记录。命令带语法错时 cron 会静默空跑，手动执行是唯一可靠的验证方式。