![“coredumpctl”无法读取核心转储,给出消息文件不可读或没有此类文件或目录?](https://linux22.com/image/164712/%E2%80%9Ccoredumpctl%E2%80%9D%E6%97%A0%E6%B3%95%E8%AF%BB%E5%8F%96%E6%A0%B8%E5%BF%83%E8%BD%AC%E5%82%A8%EF%BC%8C%E7%BB%99%E5%87%BA%E6%B6%88%E6%81%AF%E6%96%87%E4%BB%B6%E4%B8%8D%E5%8F%AF%E8%AF%BB%E6%88%96%E6%B2%A1%E6%9C%89%E6%AD%A4%E7%B1%BB%E6%96%87%E4%BB%B6%E6%88%96%E7%9B%AE%E5%BD%95%EF%BC%9F.png)
我发出以下命令:
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。我猜您的用户的 ID 为 1000,因为它是您系统上创建的第一个(也可能是唯一的)非 root 登录。
第二,系统核心转储有一些设置核心转储文件,关于允许使用多少磁盘空间。看起来如果可用磁盘空间少于 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
这样的转储曾经存在。