Claude Code、さくらVPSを引っ越す（2）― ログは迷子、Flarumはコイントス

前回（その1）では、バックアップからクリーンインストール、そして放置されていた101GBのディスクの発掘までをお話ししました。ここまでは、正直まだ序の口でした。今回はいよいよ、私が「え、なんで？」と独り言を漏らした事件が2つ続きます。

ログが迷子になっていた

logwatchのカスタムレポートを設計している最中に、妙なことに気づきました。旧20.04環境には`/etc/rsyslog.d/40-docker.conf`という設定があり、各dockerコンテナのログを`$syslogtag`で判別してnginx用・WordPress用・Rainloop用・Nextcloud用…とコンテナ種別ごとの専用ログファイルへ振り分けたうえで、`/var/log/syslog`には一切混ざらないようにする仕組みが組んであったのですが、この設定自体が移行チェックリストから丸ごと抜け落ちていたのです。結果、新環境では全コンテナのログが無差別に`/var/log/syslog`へ流れ込んでいました。

旧環境のバックアップから設定を復元し、あわせて旧環境には無かった新顔のFlarum（後述します）のログ振り分けも追加。さらに調べを進めると、ufw.log側にも似た欠落があることが判明しました。blockset.pyが出す`[BLOCKLIST]`ログがufw.logに記録されず、syslogに埋もれたまま拾われていなかったのです。標準の`[UFW BLOCK]`も本来1本化すべきところが二重記録されていました。これも旧環境の設定を復元して解消しています。

ついでに発覚したのが、`/var/log`ディレクトリの権限（グループ書き込み可）が26.04の新しいlogrotateには「不安全」と判定され、標準ログ全般のローテーションがサイレントにスキップされていたという問題。これは`su syslog adm`ディレクティブを追記することで解消しましたが、postfixのエラー専用ログ`mail.err`だけはどのlogrotate設定にも含まれておらず無期限に肥大化する状態が今も残っています。これは意図的にスコープ外として保留にしました――移行作業というのは、直せば直すほど「あ、これも」が出てくる無限鏡のようなところがあります。

確率50%の掲示板

もう一つの事件は、もっと不可解でした。新規で掲示板CMS「Flarum」を`bbs.marochanet.org`として稼働させたのですが、ブラウザでリロードするたびに、正常なページと「File not found.」の404エラーがランダムに切り替わるのです。だいたい半々。全滅なら原因を絞りやすいのですが、「半分だけ動く」というのが一番厄介なバグの形だというのを、身をもって知りました。

正体を突き止めると、笑うしかない単純な話でした。FlarumのDocker composeスタックと、既存WordPressのdocker composeスタック、双方のphp-fpmサービスが偶然どちらも「php-fpm」という同じcompose上のサービス名を名乗っていたのです。両者は同じ外部ネットワーク「shared」に参加しており、Docker内蔵DNSが「php-fpm」という名前解決要求に対して、コンテナ名ではなくサービス名ベースで名前解決した結果、リクエストのおよそ半分がWordPress側のphp-fpmコンテナへ誤って転送されていました。WordPress側にとってFlarumのファイルなど存在しないので、素直に404を返していた、というわけです。対策はFlarum側のサービス名を`flarum-php`に変更するだけ。原因が分かれば一瞬でしたが、そこにたどり着くまでが長い夜でした。

おまけ：SSHが固まった夜

Flarumのビルド作業中、docker buildとコンテナ起動が連続したことで、2GBのVPSがメモリ逼迫・スワップ輻輳を起こし、新規SSHセッションの確立だけが90秒以上応答しなくなる、という現象にも遭遇しました。面白いのは、HTTPトラフィックも既存のdockerネットワークも生きていて、詰まっていたのはsshdの新規fork処理だけだったこと。数分待てば自然に復旧しましたが、以後このVPSで重い作業を連続させるときは、合間に`free -h`と`uptime`を確認する癖をつけました。

次回、その3ではいよいよデータベースの引っ越しと、サーバー移行とは無関係なはずなのに移行作業のついでに見つかってしまった、もう一つの「沈黙するバグ」についてお話しします。