何らかの理由でcoredumpctl使用できなくなったコアファイルがないエントリの継続的なバックログがあります。出口が詰まらないように、どのように掃除できますか？
ベストアンサー1
すべてのコアダンプエントリとそのIDを一覧表示します。
coredumpctl list
または
coredumpctl list --no-pager --no-legend
コアファイルがないファイルを識別します。
これらのエントリのサイズは、ゼロまたはコアファイルがないことを示すメッセージです。
coredumpctl remove <ID>
または
ロギングダンプファイルがリストされているため、リストされていないダンプファイルを
coredumpctl list手動で削除できます。/var/lib/systemd/coredumpダンプファイルを参照し、ファイルをコマンドの結果と比較し、リストされていないファイルを削除します。
次のコマンドを使用して各項目を削除します。
rm /var/lib/systemd/coredump/core.<ID>.<executable>.core
listコマンドを再実行して、エントリが削除されたことを確認します。
保存されたすべてのダンプコアをクリーンアップするには、root
systemd-coredumpとして次のように実行できます。
systemd-tmpfiles --cleanあなたの直接の質問に答える場合は、はい。コアダンプファイルは安全に削除できます。
修正する:
ログファイルを再構築する以外に、個々のエントリを消去する直接的な方法はありませんjournalctl。これは単純な作業ではないようです。
@aviroから| OPはファイルを削除したくありません
/var/lib/systemd/coredump。正反対。彼は、利用可能なファイルのないcoredumpctlアイテム（より正確にはアイテム）を削除またはフィルタリングしようとしています。彼の苦情は、もはや利用可能なコアファイルがないアイテムの継続的なバックログがあるということでした。 _備蓄するというのは彼が。journalctl/var/lib/systemd/coredump_coredumpctl/var/lib/systemd/coredump
欠落しているアイテムのコアダンプファイルをフィルタリングするには、journalctlメッセージフィルタと一緒に使用してリストアイテムの実際のIDを置き換えることができます。
journalctl -u systemd-coredump --grep="<ID>"
いくつかの調査の終わりにログがインターリーブされているため、特定のシステムデバイスのログを削除できないことがわかりました
journalctl。
program copy_journal.py私のPython 3をログファイルに使用して 。/var/log/journal
systemdのログは、この種の変調を防ぐように設計されています。
記録されたログファイル形式ここサポート内容を説明します。オンラインフロント安全シール:
タグオブジェクトは、変更からログを封印するために使用されます。タグオブジェクトは定期的にファイルに追加されます。タグオブジェクトは、最後にタグが作成されてから、またはタグがまだ作成されていない場合、最初からファイルに保存されたオブジェクトから計算されたSHA-256 HMACタグで構成されます。 HMACのキーは、外部で維持されているFSPRGロジックによって書き込みエポックのエポックに対して計算されます。シーケンス番号 seqnum はタグごとにインクリメントされます。 [..]