![誰もがsystemdでcoredumpを使用する方法のアイデアを共有できますか？ [閉鎖]](https://linux33.com/image/141707/%E8%AA%B0%E3%82%82%E3%81%8Csystemd%E3%81%A7coredump%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%81%AE%E3%82%A2%E3%82%A4%E3%83%87%E3%82%A2%E3%82%92%E5%85%B1%E6%9C%89%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%81%8B%EF%BC%9F%20%5B%E9%96%89%E9%8E%96%5D.png)
gdbが正しい答えを提供していないときは、/var/lib/systemd/coredump/*が非常に役に立つことがわかりましたが、その理由と以前はsysvinitの世界観にあったことを理解することはできませんでした。
最近、一部のソフトウェアで分割エラーが発生したため、この問題が発生しましたが、gdbで実行すると目的の出力が得られませんでした。 /var/lib/systemd/coredump/ を実行すると、欠落しているファイルが見つかり、その一部で coredumpctl を実行でき、残りは lz4 ファイルを解凍し、そのファイルで gdb を実行してトレースを取得できました。
すべての歴史、基本は素晴らしいです。
systemd-coredump、coredumpctl、およびJournalctlのマニュアルページはそれを使用する方法についての手がかりを提供しますが、それに続く理論的根本的または推論/歴史の説明はありません。
答え1
インターフェイスは、coredumpctlを使用してコアダンプでgdbを起動することに焦点を当てているようです。
原産地は次のとおりです。v39ポイントは、メタデータをJournalctlに配置することです。
後で集まって終了同じメッセージを受け取りました（その時点でマージが難しいか拒否されましたか？）。
まだ発展が少ないようです。1年後に突然行っているとアプリのリリース回数が多いです。残念ながら、NIHのように見えます。