私はYoctoを使用してSystemDバージョン241がインストールされた小型組み込みLinuxシステム用のカスタムイメージを作成しています。ルートファイルシステムは読み取り専用です。私は/var/log/journalディレクトリが別の読み取り/書き込みパーティションに存在するようにバインドマウントとoverlayfsを使用しました。 systemd-journaldが「記憶喪失」に遭遇し、以前の開始ジャーナルが永続読み取り/書き込みファイルシステムにあるにもかかわらず、覚えていない問題に直面しました。これは、ログファイルが存在し、ファイルシステムに有効な場合でも、ログが以前の起動時の古いログファイルにアクセスまたは消去できないことを意味します。
# Setup overlayfs binds for various RW files
VOLATILE_BINDS_append = " \
/persistent-storage/var/log /var/log\n\
"
/var/log パスが存在します。
root@me:/var/log# cd /var/log/
root@me:/var/log# ls -lrt
total 9
drwxr-xr-x 2 root root 1024 Jun 3 01:50 nginx
-rw-r--r-- 1 root root 5260 Jun 9 17:56 messages
drwxr-sr-x 5 root systemd-journal 1024 Jun 9 18:00 journal
root@me:/var/log# ls -lrt journal/
total 3
drwxr-sr-x 2 root systemd-journal 1024 Jun 9 17:56 5f6085cd81114e8688cf23b3bb91933e
drwxr-sr-x 2 root systemd-journal 1024 Jun 9 17:57 de59603d1ea24e7582ed7d7ed3ac8fb0
drwxr-sr-x 2 root systemd-journal 1024 Jun 9 18:00 0c34cc794e6c4241a75774bbb8324102
/lib/systemd/journald.conf.d/10-pertant-journal.conf には、次のログ構成ファイルのフラグメントがあります。
# By default the maximum use limit (SystemMaxUse) is 10% of the filesystem, and the minimum
# free space (SystemKeepFree) value is 15% - though they are both capped at 4G.
# The journals should be rotated automatically when they reach the SystemMaxFileSize value,
# and the number of journals is controlled by SystemMaxFiles. If you prefer time based
# rotation you can set a MaxFileSec to set the maximum time entries are stored in a single journal.
[Journal]
Storage=persistent
SystemMaxFileSize=128M
SystemMaxFiles=10
SystemMaxUse=256M
SystemKeepFree=256M
SyncIntervalSec=30
問題は、数回再起動しても、ジャーナルドが正常にログを見つけて/var/log/journalに書き込むが、古いログは見つからず、以前の起動ログについてはまったくわからないということです。これは、ログがパーティションの50％を空き容量に保つ必要があるにもかかわらず、以前のログをクリーンアップできず、パーティションにスペースが不足していることを意味します。
root@me:/# journalctl --list-boots
0 82fef865e29e481aae27bd247c10e591 Tue 2020-06-09 18:00:12 UTC—Tue 2020-06-09
18:15:23 UTC
しかし：
root@me:/# ls -lrt /var/log/journal/
total 3
drwxr-sr-x 2 root systemd-journal 1024 Jun 9 17:56 5f6085cd81114e8688cf23b3bb91933e
drwxr-sr-x 2 root systemd-journal 1024 Jun 9 17:57 de59603d1ea24e7582ed7d7ed3ac8fb0
drwxr-sr-x 2 root systemd-journal 1024 Jun 9 18:00 0c34cc794e6c4241a75774bbb8324102
また、次のコマンドも有効です。
root@me:/# journalctl -b 0
<information>
root@me:/# journalctl -b 1
<information>
root@me:/# journalctl -b 2
Data from the specified boot (+2) is not available: No such boot ID in journal
私はこの記事を読みました：/ではなく、ファイルシステムのログパスになることができますか？。次のマウントファイルを試しましたが、まったく同じ動作が表示されます。
[Unit]
Description=Persistent Journal Storage Bind
[Mount]
What=/anotherfs/journal
Where=/var/log/journal
Type=none
Options=bind
[Install]
WantedBy=local-fs.target
何が間違っていて、バインドマウントシステムで永続ログを使用するようにログを取得するにはどうすればよいですか？
答え1
私はしばらく同じ問題で苦労しています。読み取り専用のrootfsと揮発性バインディングを使用して、他のパーティションにマウントされた/ var / logフォルダを持つYoctoベースのディストリビューションがあります。ロギングを新しいパーティションに移動すると、同じことがわかりました。journalctl --list-boots以前の起動ではなく現在の起動のみが表示されます。後ろにたくさん数回の試行錯誤の末、ついにその理由を見つけました。
指摘したように、/var/log/journal3つのフォルダが表示されます。
root@mir-edb-intel-gen1:~# ls -lrt /var/log/journal/
total 24
drwxr-sr-x+ 2 root systemd-journal 4096 Mar 5 09:24 7f7f3d516b554d718d688a0b0fa9648e
drwxr-sr-x+ 2 root systemd-journal 4096 Mar 5 09:25 93eb74229e9244a4b7f60c90acacc12f
drwxr-sr-x+ 2 root systemd-journal 4096 Mar 5 10:57 4a9652b4b33a4a099bdc6be8c6fb2b1a
項目journalctl --list-bootsは1つだけ表示されます。
0 6cb4f9f236954f69937be217f36c1ce2 Fri 2021-03-05 10:57:48 UTC—Fri 2021-03-05 11:01:22 UTC
ただし、3つの実行をすべて実行すると、期待journalctl -D /var/log/journal --list-bootsどおりに表示されます。
root@mir-edb-intel-gen1:~# journalctl -D /var/log/journal --list-boots
-2 9ab6d00dea9d41da9c76bf2a3f64895c Fri 2021-03-05 09:24:20 UTC—Fri 2021-03-05 09:25:03 UTC
-1 00509584245d44d599d88db8dccd4177 Fri 2021-03-05 09:25:37 UTC—Fri 2021-03-05 10:14:42 UTC
0 6cb4f9f236954f69937be217f36c1ce2 Fri 2021-03-05 10:57:48 UTC—Fri 2021-03-05 11:01:22 UTC
systemdについてはよくわかりませんが、ログをフラッシュしているので問題が発生すると思います。/実行/ログ/ログ到着/var/log/log起動するたびに、既存のログインに詳細を書き込む代わりに/var/log/log。その後、呼び出すjournalctlと最新のフォルダしか表示されないため、フォルダ全体を表示するように特に指示しない限り、以前の実行が見つかりません。/var/log/log。
編集する： @JapJorisビンス行動の良い説明があるようです。この回答
編集2：
私たちの場合、/etc/machine-idファイルは以下のように空のファイルですpoky/meta/classes/rootfs-postcommands.bbclass。
#
# A hook function to support read-only-rootfs IMAGE_FEATURES
#
read_only_rootfs_hook () {
[...]
if ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", "false", d)}; then
# Create machine-id
# 20:12 < mezcalero> koen: you have three options: a) run systemd-machine-id-setup at install time, b) have / read-only and an empty file there (for stateless) and c) boot with / writable
touch ${IMAGE_ROOTFS}${sysconfdir}/machine-id
fi
}
答え2
システムジャーナルmountシステムの起動初期段階で（）を開始することは、/var/logサービスの開始後に発生する可能性があります /var/log。 RWパーティションをマウントする方法の詳細が必要です。
jounraldシステムの起動後、サービスを再起動してみることができます。
Storage=ログデータが保存される場所を制御します。 「揮発性」、「持続的」、「自動」、「なし」のいずれかです。 「揮発性」の場合、ジャーナルログデータはメモリ、つまり/run/log/journal階層（必要に応じて作成）にのみ保存されます。 「持続的」の場合、データは最初にディスクに保存されます。つまり、/var/log/journal階層（必要に応じて作成）に保存され、/run/log/journal（必要に応じて作成）に置き換えられ、早期起動ディスクは書き込めません。 「自動」は「永続」に似ていますが、必要に応じて/ var / log / journalディレクトリが作成されないため、このディレクトリの存在はログデータの移動場所を制御します。 「none」はすべてのストレージをオフにし、受信したすべてのログデータを削除します。ただし、他の宛先（コンソール、カーネルログバッファ、syslogソケットなど）への転送は引き続き機能します。デフォルトのログ名前空間では、デフォルトは「auto」、他のすべての名前空間では「percious」です。
答え3
考えられる解決策は、/var/log/journalから別のパーティションへのシンボリックリンクです。
私の読み取り専用rootfs Yoctoシステムでは、アプリケーションを起動するシステムサービスの1つにこのシンボリックリンクが設定されています。すべてのログは、シンボリックリンクが所定の位置になるまでRAMに保存され、シンボリックリンクパーティションにフラッシュされます。
mkdir -p /data/log/journal
systemd-tmpfiles --create --prefix /data/log/journal
ln -s /data/log/journal /var/log/journal
journalctl --flush
答え4
ログが/run/log/journal/生成された後も記録されますか？/var/log/journal/その場合は、揮発性ディレクトリから読み続けることができます/run/。
# journalctl --list-bootsrunningとの間で他のパラメータを変更しましたか# journalctl -b 1？これは、出力結果が存在しないファイルから読み取るように見えるためです。どの構成で実行しても# journalctl -b 1永続性は維持されているようです。
申し訳ありません。答えよりもコメントに適していると思いますが、まだコメントできる評判が十分ではありません。