Paul Knopf's questions

我正在使用嵌入式 Linux 设置。我挂载了一个带有可写覆盖（使用overlayfs）的 squashfs，然后 chroot 进入其中，将控制权转移到 systemd。

我在 systemd 中有补丁可以将核心转储发送到/var/log，而不是/var/lib/systemd/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

命令

pamtester -v auth pknopf authenticate
pamtester: invoking pam_start(auth, pknopf, ...)
pamtester: performing operation - authenticate
Password:
pamtester: Authentication failure

杂志

Feb 06 13:22:17 PAULS-ARCH unix_chkpwd[31998]: check pass; user unknown
Feb 06 13:22:17 PAULS-ARCH unix_chkpwd[31998]: password check failed for user (pknopf)
Feb 06 13:22:17 PAULS-ARCH pamtester[31997]: pam_unix(auth:auth): authentication failure; logname= uid=1000 euid=1000 tty= ruser= rhost=  user=pknopf

就目前而言，每个锁定屏幕都会阻止我“解锁”（KDE 锁定屏幕i3lock等）。

如果我以 开头i3lock，sudo然后我可以正确输入root密码来解锁屏幕。但是，如果我以普通用户身份运行它，则无法使用普通用户或 root 密码解锁。

这是我的 PAM 配置i3lock。

#
# PAM configuration file for the i3lock screen locker. By default, it includes
# the 'system-auth' configuration file (see /etc/pam.d/login)
#
auth include system-auth

跑步ls -l /etc/passwd /etc/shadow /etc/group节目

-rw-r--r-- 1 root root 803 Feb 6 14:16 /etc/group
-rw-r--r-- 1 root root 1005 Feb 6 14:16 /etc/passwd
-rw------- 1 root root 713 Feb 6 14:16 /etc/shadow

这是 Arch 的全新安装，所以我不认为配置太不稳定。我应该寻找什么来调试这个？

跑步ls -l /sbin/unix_chkpwd节目

-rwxr-xr-x 1 root root 31392 Jun  9  2016 /sbin/unix_chkpwd

如果您有权访问/etc/passwd和/etc/shadow，是否可以找出密码是什么？我知道你可以重置它，但有没有办法恢复它？