次のコマンドを発行します:
coredumpctl list
Mon 2019-11-18 23:58:19 GMT 19043 1000 1000 31 missing /opt/google/chrome/chrome
Mon 2019-11-18 23:58:19 GMT 19062 1000 1000 31 missing /opt/google/chrome/chrome
Tue 2019-11-19 15:52:55 GMT 22332 1000 1000 6 missing /usr/bin/texstudio
に続く：
coredumpctl gdb 22332
Storage: /var/lib/systemd/coredump/core.texstudio.1000.bb1cfb6b67f2423fac681d721ee1ba02.22332.1574178774000000.lz4 (inaccessible)
File "/var/lib/systemd/coredump/core.texstudio.1000.bb1cfb6b67f2423fac681d721ee1ba02.22332.1574178774000000.lz4" is not readable: No such file or directory
これにより、スタック トレースがダンプされ、ストレージにアクセスできないことと、ファイルが読み取り不可または見つからないことに関する上記の 2 つのメッセージが表示されます。
何か間違ったことをしているのでしょうか?
答え1
よくある間違いは 2 つあります。
多くの場合、コア ダンプは、プログラムが別のユーザー ID で実行されたために「アクセス不能」になります。これは、権限がないことを意味します。簡単な解決策は、coredumpctlたとえば . を使用して、root として実行することですsudo coredumpctl。
それはあなたの問題ではないと思います。これらのコアダンプは、ユーザー ID 1000 からのものです。これは、システムで作成された最初の (そしておそらく唯一の) 非ルート ログインであるため、ユーザーの ID は 1000 であると思われます。
第二に、systemd-コアダンプいくつかの設定がありますコアダンプ.conf、使用できるディスク容量について。空きディスク容量が 15% 未満の場合、コア ダンプはまったく作成されないようです。(この設定を変更しない限り)
df -hまたはコマンドを使用して、使用可能なディスク容量を確認できますdf -h /var/lib/systemd/coredump/。
(コア ダンプで使用される合計絶対サイズを確認するには、 を実行しますdu -sh /var/lib/systemd/coredump/。)
最大使用数=、空き容量=
外部に保存されたコアダンプが占めるディスク容量の制限を強制します。MaxUse= は、コアダンプが占めるディスク容量の合計がこの制限 (デフォルトはディスク容量全体の 10%) を超えるとすぐに古いコアダンプが削除されるようにします。KeepFree= は、少なくともどれだけのディスク容量を空けておくかを制御します (デフォルトはディスク容量全体の 15%)。コアダンプが処理されている間、コアダンプが使用するディスク容量が一時的にこれらの制限を超える可能性があることに注意してください。古いコアダンプは、systemd-tmpfiles(8) を介して時間に基づいて削除されることにも注意してください。サイズベースのクリーンアップをオフにするには、どちらかの値を 0 に設定します。
答え2
各ダンプにはと表示coredumpctl listされ、最終的なエラー メッセージは であったことに注意してください。missingNo such file or directory
お使いのディストリビューションには、古いコア ダンプをクリーンアップする定期的な cron ジョブ/systemd タイマーがあると思います (毎週でしょうか?)。実際のコア ダンプ ファイルはクリーンアップされ、coredumpctlそのようなダンプが存在していたことを示す小さなログ エントリだけが残りました。