Uma vez por mês, descubro que um dos meus servidores RedHat 9 foi reiniciado (na verdade, é o AlmaLinux 9, mas como é um clone do RH9, essa questão provavelmente é melhor resolvida no contexto do RH9). Estou tentando descobrir o que está causando o travamento, mas não há arquivos de despejo de núcleo criados!
Eu segui as instruções neste post , exceto que parece que não tenho nada compatível no meu sistema, mas quando eu aciono um core dump com:
durma 3 e mate -SEGV $!
não há nenhum arquivo de despejo de núcleo!
Confirmei que os princípios básicos estão definidos com:
[root@myhost ~]# cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
[root@myhost ~]# ulimit -c
unlimited
Há algo mais que eu deva definir para deixar o arquivo de despejo ser criado? Suspeito que meu próprio aplicativo (não empacotado) esteja causando o problema... mas não há nenhum arquivo core nem mesmo no diretório que contém o aplicativo.
====ATUALIZAÇÃO====
Modifiquei /etc/coredump.conf e configurei storage=external (todo o resto comentado), depois reiniciei e executei o seguinte:
[root@myhost ~]# sleep 3 & kill -SEGV $!
[1] 3583
[root@myhost ~]#
[1]+ Segmentation fault (core dumped) sleep 3
[root@myhost ~]# coredumpctl --all
TIME PID UID GID SIG COREFILE EXE SIZE
Sat 2024-10-26 12:56:46 EDT 3583 0 0 SIGSEGV none /usr/bin/bash -
[root@myhost ~]# ll /var/lib/systemd/coredump/
total 0
Então ainda não há arquivos de dump de núcleo visíveis (e observe o "nenhum" acima). O log do sistema mostra:
Oct 26 13:06:41 ngcvls1 systemd[1]: Started Process Core Dump (PID 4459/UID 0).
Oct 26 13:06:41 ngcvls1 systemd-coredump[4460]: Resource limits disable core dumping for process 4458 (bash).
Oct 26 13:06:41 ngcvls1 systemd-coredump[4460]: Process 4458 (bash) of user 0 dumped core.
Então, na linha de comando eu executei:
ulimit -c unlimited
e repeti o teste de segfault, então um arquivo core foi criado! Mas na reinicialização ele desapareceu. (Apesar de eu ter storage=external definido em coredump.conf). Preciso de core dumps para sobreviver a reinicializações, caso contrário não consigo dizer por que meu sistema travou. Chegando perto! Gostaria de tornar ulimit -c permanente, mas não tenho certeza de onde colocar isso (não gosto do conselho de outras postagens para colocar em .bashrc)
Forneci algumas informações em outra resposta , mas o
coredumpctlcomando sem argumentos deve listar quaisquer core dumps conhecidos. Essas informações são mantidas no diário do systemd. Se você estiver excluindo ou não mantendo o diário, não terá essas informações.O Systemd mantém seus arquivos principais em
/var/lib/systemd/coredump/, mesmo que o diário tenha sido limpo, eu acho.Para impedir que o systemd assuma o controle do core dump, você pode fazer
A primeira linha substitui a configuração
/usr/lib/sysctl.d/50-coredump.confpara futuras inicializações. A segunda linha altera a configuração imediatamente.Existem outras configurações que podem afetar se os dumps de núcleo são feitos pelo systemd, em arquivos
Veja
man coredump.conf. O arquivo pode mostrar os valores padrão como comentários. A entradaStorage=externalsignifica que o arquivo core estará no diretório/var/lib/systemd/coredump/, caso contrário, eles serão mantidos dentro dos arquivos de log do diário.Se o processo for maior que
ProcessSizeMax=o dump será registrado, mas nenhum core dump será feito. Da mesma forma, nenhum core dump seExternalSizeMax=for excedido, ouJournalSizeMax=, dependendo da sua escolha de armazenamento. Nenhum core se os dumps já ocuparem mais deMaxUse=por cento do espaço em disco, ou se houver menosKeepFree=espaço disponível. Meu Fedora 38 temPara RHEL 9, consulte aplicativos de depuração .