先看现象。Ubuntu 22.04 上按网文改 journald.conf，把 ForwardToSyslog 设成 no，之后 /var/log/syslog 里再看不到 sshd 与 cron 的记录，fail2ban 的封禁计数也不动了。
原因不止一个，得分开看。ForwardToSyslog=no 后 journald 不再把日志转给 rsyslog，/var/log/syslog 只剩 rsyslog 自己产生的那部分。也可能是优化脚本顺手把 Storage 改成 volatile，重启后日志全部丢。
少数情况下是部分审计脚本和 fail2ban 直接读 /var/log/auth.log，文件不再增长就失效。
先确认当前的两个开关
grep -E 'ForwardToSyslog|Storage' /etc/systemd/journald.conf接着改回转发并持久化
ForwardToSyslog=yes Storage=persistent然后重启两个服务
systemctl restart systemd-journald rsyslog交叉核对日志是否落盘
journalctl -u ssh -n 5; tail -n 5 /var/log/auth.log隔了一天再看，现象没变，说明不是偶发。
那几天正好在做别的变更，先把时间线对齐才敢动手。
排查用的命令都是临时敲的，没有写成脚本，事后才整理。
恢复的判定其实很直接。/var/log/syslog 与 auth.log 里出现新的 sshd 与 CRON 记录，fail2ban-client status sshd 的失败计数重新变化，journalctl 与文件内容能对上。
journald 和 rsyslog 是上下游关系，关掉转发只影响文件不影响 journalctl；按网文改之前先 grep 一遍依赖这些日志文件的程序。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。