Paul Knopf's questions

Estou em uma configuração de Linux embarcado. Eu monto um squashfs com uma sobreposição gravável (usando overlayfs) e depois faço chroot nele, transferindo o controle para o systemd.

Eu tenho patches no systemd para enviar os coredumps /var/log, em vez de /var/lib/systemd/coredump.

Quando um coredump é solicitado, systemd-coredumpé invocado, mas obtém esse erro.

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.

Meu /proc/sys/kernel/core_patterné |/lib/systemd/systemd-coredump %P %u %g %s %t %c %e. Se eu definir o core_patternpara /tmp/cores/core.%e.%p.%h.%t, ele funciona. Então, é algo def com systemd.

Estou usando o systemd versão 237. Isso funcionou anteriormente com o systemd versão 234.

Meu sistema de arquivos está correto/limpo. Não está corrompido de forma alguma ( fsckvolta limpo).

Como faço para que o systemd gere dumps principais sem erros?

EDIÇÃO #1

Eu recompilei systemd-coredumppara logar em diretórios diferentes, até mesmo um pen drive montado, e isso me dá o mesmo erro.

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

Estou começando a pensar que o kernel ou systemd está fazendo algo diferente de simplesmente criar um arquivo temporário.

EDIÇÃO #2

Eu executei a openchamada exata que o systemd faz no espaço do usuário e foi bem-sucedido. Existe algo sobre o contexto em que o kernel invoca o dumper de núcleo?

Eu adicionei esta linha ao 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;
    }

Eu recebo essa saída.

Couldn't open: -1: /run/media/Pauls/.#core.ClearApp.0.7833dca6d3354c0e959b366df731bf9f.879.15329633730000000f174d1155a09d96

Comando

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

diário

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

Como está agora, todas as telas de bloqueio me impedirão de "desbloquear" (tela de bloqueio do KDE, i3lock, etc).

Se eu começar i3lockcomo sudo, posso digitar corretamente a senha do root para desbloquear a tela. No entanto, se eu executá-lo como usuário normal, não consigo usar o usuário normal ou a senha root para desbloquear.

Aqui está minha configuração de PAM para arquivos 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/groupShows em execução

-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

Esta é uma nova instalação do Arch, então não acho que a configuração seja muito instável. O que devo procurar para depurar isso?

ls -l /sbin/unix_chkpwdShows em execução

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

Se você tiver acesso a /etc/passwde /etc/shadow, é possível descobrir qual é a senha? Eu sei que você pode redefini-lo, mas existe uma maneira de recuperá-lo?