cPanel 域名日志轮转后 0 字节？apache 需要 graceful reload
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'
两个错误同时现形：
- 语法错：
-q是fail2ban-client的全局选项，必须放在子命令前面（fail2ban-client -q reload）；写在reload后面被当成 jail 名解析，直接报错退出 - 对象错：就算语法对了，
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 新机排障图。
注意事项
cron 的失败是静默的：命令写错、报错退出，都不会有人收到通知。任何「防断流」「自动兜底」类 cron，部署后必须手动执行一遍命令本身验证——本例的语法错，手动跑一次当场就能抓住，靠等它起作用才发现就是三天后了。另外 fail2ban-client 的 -q 这类全局选项，位置错了会被解析成 jail 名，报错信息（No section: '-q'）并不会提示「位置错了」。
常见问题
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 会静默空跑，手动执行是唯一可靠的验证方式。