要注意！systemd-journaldのログ書き込みが肥大化してディスクを圧迫する問題

systemd-journaldのログがext4ファイルシステムで49KB以上、btrfsでは110KB以上もの巨大な書き込みを発生させており、ディスクI/Oを圧迫しているようです。

https://github.com/systemd/systemd/issues/40262#issuecomment-5169482357

最近journaldのディスク使用量を調べてみて愕然としたよ。心の平穏を得るために次はhttps://www.devuan.org/os/init-freedom を試してみるつもり。Debianシステムの次のディストリビューションとして使ってみる予定。別のマシンでVoid Linux (runit)を長く使ってるけど、最高だよ。

おっと、mmappedの書き込みか。何年か前に私も同じミスをしたよ。:) そのGitHubのissueにコメントしておいた。

個人的には、journaldはsystemdエコシステムの中で最悪のゴミだと思う。ルーターとしてだけ使って、ログを保存しないのが賢明だよ。使われているインデックスシステムは遅いし、おしゃべりなサブシステムを制御する術もない。特定の識別子のログだけを切り捨てるようなこともできないしね。インデックス機能の恩恵を考えても、agやrgのような最近のgrepツールを使った方がずっとパフォーマンスが良い。構造化されていること自体は価値があるけど、journaldでやるべきことじゃないね。

@ValdikSSがここにいるのを見るのは嬉しいね。この人、寝てないんじゃないか、それとも実はAIなんじゃないか？ ;-)

Windows NTのイベントログをコピーしようとして、なぜこれほど盛大に失敗できるんだろう？あれはRAMが32MB以下だった1990年代からほとんど変わっていないものなのに。Linuxシステムで最初にやることは、まともなsyslogデーモンをインストールすることだね。

なるほど。じゃあsystemdを完全に削除せずに、journaldを無効化して他のものに切り替えるにはどうすればいい？

途中で何かが起きたんだろうね。だってこれはデータベースの当初の設計意図とは明らかに違うから（強調は筆者によるもの）： "ネイティブなジャーナルファイル形式は、古典的なログファイルやgitリポジトリからインスピレーションを得ている。ログデータは末尾に追記されるよう設計されており（mmapベースのアクセスによる堅牢性と原子性を確保するため）、ヘッダー内のメタデータ変更によって新規追加分を参照する。エントリを構成するフィールドは、ジャーナルファイル内で個別のオブジェクトとして保存され、必要に応じてすべてのエントリから参照される。ジャーナルエントリは非常に繰り返しが多いため、これでディスク容量を大幅に節約できる（例えば、すべてのローカルメッセージには同じ_HOSTNAME=や_MACHINE_ID=フィールドが含まれる）。データフィールドはディスク容量節約のために圧縮される。純粋な効果として、ジャーナルは従来のsyslogよりも大幅に多くのメタデータを記録するが、ディスク占有量はすぐには反映されない。" 詳細は https://docs.google.com/document/u/0/d/1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs/pub を見て。

さらに最悪なのは、journaldを実質的にフィルタリングできないことだよ。唯一の選択肢は重要度による制限（エラー以上など）か、ジャーナルの永続保存をオフにしてrsyslogに転送し、そっちでフィルタリングすることぐらい。細かい詳細は曖昧だけど、たまにドライバーが暴走して1秒間に何回もログを吐くことがある。例えばサスペンド復帰後のamdgpuのバグとかね。フィルタリングするのにかなり時間がかかったけど、幸いにもカーネルメッセージ（dmesg）だったから対応できた。でも一時期はカーネルの永続ログを無効にせざるを得なくて、全く理想的とは言えない状況だった。特定のコアパーツにおいてシンプルさが機能より優先されるのは理解できる。でもjournaldは永続ストレージを有効にするにはあまりにも基礎的すぎるし、かといって無効にするのも嫌なんだ。

journaldは多くの理由で酷いけど、さらに最悪なのはマシン上で動いているすべてのものが、勝手にやりたい放題ログを吐き出してもいいと思っていることだ。ファイル選択ダイアログを開くだけで、kioが一日何十万件ものログをスパムするのがいいアイデアだと判断したりする。「削除されたアイテムのノードが見つかりません」といったログがディレクトリ内の全ファイル分出力されるけど、ユーザーにとっては全く意味がない。新しいサービスが追加されるたびに、システムログをごみ捨て場にされないよう、ログの氾濫を追跡するスクリプトを維持しなきゃいけないくらいだよ。公平に言えば、カーネルやUSB周辺機器も不調になると、入力irqステータス-75のようなログを1時間に300万行も吐くことがあるから困る。プログラムレベルの設定やサービスファイルをすべて管理するのは大変だけど、systemdのLogFilterPatternsが予期せぬ形で役に立つ。/etc/systemd/system/service.d/ に.confファイルを置いてログのブラックリストを作れば、ログレベルの管理なんて気にせずに一つずつパターンを登録できるんだ。こんな感じに： [Service] LogFilterPatterns=~私は全く無用なログエントリです LogFilterPatterns=~私は別の無用なログエントリです。でも識別子を拾えないし、カーネルのスパムには効果がない。特定のメッセージを黙らせるには便利だね。あと、キャッシュやジャーナルにnocowを設定していないbtrfs環境は欠陥品だと思う。