我在嵌入式Linux安装程序上。我用一个可写覆盖(使用overlayfs)挂载了一个squashfs,然后将控件转移到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,它就能工作。所以,这是与系统d有关的。
我使用的是systemd版本237。以前,这种方法适用于systemd版本234。
我的文件系统是正确的/干净的。不管怎么说,它都没有损坏(fsck回来干净了)。
如何使系统生成没有错误的核心转储?
我重新编译了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所做的不仅仅是创建临时文件。
我在userspace上运行了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发布于 2018-07-31 06:22:04
这已经在GitHub (#9756)中得到了回答。
对于后代:“coredump服务使用ProtectSystem=strict和ProtectHome=yes集运行,这意味着除了StateDirectory=中列出的路径(即/var/lib/systemd/coredump/)之外,它不能在任何地方写入。”
在其他地方(例如/var/log/的子目录)保存代码转储的建议方法是将该目录绑定到/var/lib/systemd/coredump/。
https://unix.stackexchange.com/questions/459348
复制相似问题