我使用嵌入式 Linux 设置。我安装了一个带有可写覆盖层的 squashfs(使用overlayfs
),然后 chroot 进入其中,将控制权转移给 systemd。
我在 systemd 中有补丁可以将核心转储发送到/var/log
,而不是/var/lib/systemd/coredump
.
当请求 coredump 时,systemd-coredump
会调用 ,但会出现此错误。
Jul 30 08:54:14 evo4k-e6872f kernel: ClearApp[803]: segfault at 0 ip 000000000042bcb0 sp 00007ffcd4915f18 error 6 in ClearApp[400000+868000]
Jul 30 08:54:14 evo4k-e6872f kernel[359]: ClearApp[803]: segfault at 0 ip 000000000042bcb0 sp 00007ffcd4915f18 error 6 in ClearApp[400000+868000]
Jul 30 08:54:14 evo4k-e6872f systemd[1]: Started Process Core Dump (PID 804/UID 0).
Jul 30 08:54:14 evo4k-e6872f systemd-coredump[805]: Failed to create temporary file for coredump /var/log/coredump/core.ClearApp.0.54a13c5624ad4ed6b3>
Jul 30 08:54:14 evo4k-e6872f systemd-coredump[805]: Process 803 (ClearApp) of user 0 dumped core.
Jul 30 08:54:14 evo4k-e6872f systemd[1]: clearapp.service: Main process exited, code=dumped, status=11/SEGV
Jul 30 08:54:14 evo4k-e6872f systemd[1]: clearapp.service: Failed with result 'core-dump'.
Jul 30 08:54:15 evo4k-e6872f systemd[1]: clearapp.service: Service hold-off time over, scheduling restart.
Jul 30 08:54:15 evo4k-e6872f systemd[1]: clearapp.service: Scheduled restart job, restart counter is at 5.
Jul 30 08:54:15 evo4k-e6872f systemd[1]: Stopped MedX ClearApp.
Jul 30 08:54:15 evo4k-e6872f systemd[1]: clearapp.service: Start request repeated too quickly.
Jul 30 08:54:15 evo4k-e6872f systemd[1]: clearapp.service: Failed with result 'core-dump'.
Jul 30 08:54:15 evo4k-e6872f systemd[1]: Failed to start MedX ClearApp.
我/proc/sys/kernel/core_pattern
的是|/lib/systemd/systemd-coredump %P %u %g %s %t %c %e
。如果我设置core_pattern
为/tmp/cores/core.%e.%p.%h.%t
,它就会起作用。所以,这肯定是 systemd 的事情。
我使用的是 systemd 版本 237。这之前适用于 systemd 版本 234。
我的文件系统是正确/干净的。无论如何它都没有损坏(fsck
恢复干净)。
如何让 systemd 生成没有错误的核心转储?
编辑#1
我重新编译systemd-coredump
以登录到不同的目录,甚至是安装的拇指驱动器,它给了我同样的错误。
Jul 30 10:43:39 evo4k-e6872f systemd-coredump[1910]: Failed to create temporary file for coredump /run/media/Pauls/core.ClearApp.0.dd6557bb31264bf2b3773b534fd6e2b1.1908.1532961819000000: Read-only file system
我开始认为内核或 systemd 正在做一些事情,而不仅仅是创建临时文件。
编辑#2
我从用户空间运行了 systemd 所做的确切open
调用,并且成功了。内核调用核心转储程序的上下文是否存在某些情况?
我将这一行添加到 systemd 中。
fd = open(tmp, O_CREAT|O_EXCL|O_NOFOLLOW|O_NOCTTY|flags, 0640);
if (fd < 0) {
log_error("Couldn't open: %d: %s", fd, tmp);
return -errno;
}
我得到这个输出。
Couldn't open: -1: /run/media/Pauls/.#core.ClearApp.0.7833dca6d3354c0e959b366df731bf9f.879.15329633730000000f174d1155a09d96
答案1
这个问题已经在 GitHub 上得到了解答(第9756章)。
对于后代:“ coredump 服务是通过ProtectSystem=strict
并ProtectHome=yes
设置来运行的,这意味着它不能写入除StateDirectory=
ie中列出的路径之外的任何地方/var/lib/systemd/coredump/
。”
建议将 coredump 保存到其他位置(例如 的子目录/var/log/
)的方法是将该目录绑定挂载到/var/lib/systemd/coredump/
。