
CentOS 7 を実行しているシステムがあり、空きディスク容量は 1T を超えています。systemd のバージョンは 219 です。journald を次の設定で構成しました。
Storage=persistent
SplitMode=none
SystemMaxUse=50G
SystemMaxFileSize=1G
#MaxFileSec=1month (default)
ただし、結果として得られるジャーナル ファイルは 1G より小さく、このスクリーン ショットでわかるように、約 500M で切り詰められます。
システムの徹底的なテストを行っていますが、ログには 1 日あたり 1G 以上が記録されています。したがって、MaxFileSec が機能しているわけではありません。ファイルのグループ ID が異なることに気付きました。これが手がかりかもしれません。ただし、スクリーンショットのタイムスタンプからわかるように、上部の 2 つのログ ファイルはもういっぱいになっていないようです。
私の質問は、ジャーナル ファイルのサイズが構成された 1G に達しないのはなぜかということです。
編集: 下記のマークが指摘したようにパラメータ名を修正しました。ただし、システム上では正しいものでした。
答え1
のドキュメントには、man journald.conf
ログ ファイルを と同じ大きさにすることを約束するものはありませんSystemMaxFileSize=
。ドキュメントでは、その制限を超えないことのみを約束しています。
素人の読書からCソースコード私の解釈では、「最小ファイル サイズ」はありますが、これは 512k しかないので、ここでは関係ありません。また、「FILE_SIZE_INCREASE」もありますが、これは増分ファイル増加の割り当てに関連しています。私の解釈では、ローテーションが発生する前に、ファイル サイズが SystemMaxFileSize の 8 MB 以内に増加すると予想されます。
systemd
ソースツリー全体で を検索するとSystemMaxFileSize
、それが上にリンクされた「.c」ファイル内の「max_size」変数に変換されていることがわかります。
ドキュメントでは質問に完全に答えられなかったため、関連するソース コードを読むことで、探していた動作についてより詳しく理解できる可能性があります。