私は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/journal
3つのフォルダが表示されます。
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
}