
我發出以下命令:
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
它轉儲堆疊追蹤並給出上述兩條有關儲存無法存取和檔案無法讀取或找到的訊息。
難道我做錯了什麼?
答案1
有兩件常見的事情你可能會犯錯。
通常,核心轉儲“無法存取”,因為該程式以與您不同的使用者 ID 運行。這意味著您沒有權限。快速解決方案是以 root 身份運行coredumpctl
,例如使用sudo coredumpctl
.
我想這不是你的問題。這些核心轉儲來自用戶 ID 1000。
第二,系統核心轉儲有一些設置核心轉儲文件,關於允許使用多少磁碟空間。看起來如果可用磁碟空間少於 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
說明,最終的錯誤訊息是。missing
No such file or directory
我猜你的發行版有一個定期的 cron 作業/systemd 計時器,可以清理舊的核心轉儲(也許每週一次?)。它已經清理了實際的核心轉儲文件,並且只留下了一個小的日誌條目,表明coredumpctl
這樣的轉儲曾經存在。