linuxサーバを運用していて、/var/log/を確認すると、messagesやcronにログが出力されておらず、ファイルサイズが0バイトになっていた時のトラブルシューティングです。
現象（messagesファイルが0バイト）
/var/log/messages、cron、maillogにログが出力されておらず、ファイルサイズが0バイトになっていました。apacheの/var/log/httpd/access_logや、iptablesのログを別途出力してる/var/log/iptables（※1）には問題なく出力されいている状況でした。
出力されなくなった時期を確認すると、どうもパッチ（dnf update）を実施した後から。パッチ適用直後もmessagesファイルを確認していたのですが、そこで出力が停止している事には気が付いていませんでした。
原因（rsyslog.confの記載内容に問題あり）
先に結論を記載すると、/etc/rsyslog.confに記載している内容に問題がありました。パッチ適用前はその記述でも問題なかったのですが、パッチ適用後にエラーとなってしまっていたようです。
具体的には、※1のとおり、iptablesのログをmessagesではなく、個別のファイルに分けるようにしていた部分（iptablesのログ出力が多く、messagesに出力すると見にくくなるのを避けるためで、/etc/rsyslog.conf に
:msg, contains, "IPTABLES" -/var/log/iptables
:msg, contains, "IPTABLES" & ~という記述をしていましたが、これを、
:msg, contains, "IPTABLES" -/var/log/iptables
& stopに修正して、rsyslogdを再起動すると無事ログが出力されるようになりました。
まず、 ~ を使うと警告が表示されるようになっており、 stop を使うのが正しいようです。これを指定すると以降のログは破棄される形になります。つまり、messagesには出力されません。
また、& は、直前のパターンにマッチしたもの、という意味になるのですが、フィルター（:msg, contains）の直後に記載することでおかしく判定されていたようです。今回の挙動から、すべてのログを破棄しているような感じになっていました。（パッチ適用前はなぜこれで正しく動いていたか謎ですが…）
トラブルシューティングの内容
実際にどのようにして、切り分けていったかを記載します。
まず、rsyslogdのサービスを再起動しました。結果、状況は変わりませんでした。
次に、/var/lib/rsyslog/imjournal.state を、別名でリネームして、journald のサービスを再起動しました(systemctl restart systemd-journald.service)。新しいstateファイルができましたが状況は変わりませんでした。
念のため、もう一度、rsyslogdのサービスを再起動しましたが、変化はありませんでした。
/var/log/messageに何も表示されないので、どこを調べればよいか、と思ったときに、journalログには何か出ていないか、と思い、journalctl コマンドを実行しました。
結果、これがビンゴでした。journalログにはエラーが出ており、/etc/rsyslog.confのファイルがおかしいよと、きちんと記録されておりました。
/etc/rsyslog.confの変更前のオリジナルファイルを、rsyslog.conf.orgとして保存していたので、diffコマンドで差分を確認し、上記のiptablesの部分を洗い出すことができました。
ちなみに、journalctlコマンド他、ジャーナルログを調査するコマンドやオプションがたくさんある事を今回初めて知りました。何かあったときは、/var/log/messagesだけでなく、ジャーナルログを確認する必要があることを学びました。
今回はここまでです。最後までお読みいただきありがとうございました。