Out Of Memory - Killed process Systemd-jounal

fsantanajr
(usa Outra)

Enviado em 24/09/2021 - 13:14h

Estou com este erro após rodar o yum update no OL 7. O Kernel a ser iniciado é o Oracle Linux Server 7.9, with Unbreakable Enterprise Kernel 5.4.17-2102.205.7.3.el7uek.x86_64.

Quando inicio por ele, o erro anexo de Out Of Memory : Killed Process... acontece e não consigo subir o servidor.

Versão do OL7:

[root@oracle ~]# cat /etc/*release
Oracle Linux Server release 7.9
NAME="Oracle Linux Server"
VERSION="7.9"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"
PRETTY_NAME="Oracle Linux Server 7.9"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:7:9:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 7"
ORACLE_BUGZILLA_PRODUCT_VERSION=7.9
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=7.9
Red Hat Enterprise Linux Server release 7.9 (Maipo)
Oracle Linux Server release 7.9
[root@oracle ~]#
KERNEL INSTALADOS

[root@oracle ~]# awk -F\' '$1=="menuentry " {print i++ " : " $2}' /etc/grub2.cfg
0 : Oracle Linux Server 7.9, with Unbreakable Enterprise Kernel 5.4.17-2102.205.7.3.el7uek.x86_64
1 : Oracle Linux Server 7.9, with Unbreakable Enterprise Kernel 5.4.17-2102.205.7.2.el7uek.x86_64
2 : Oracle Linux Server 7.9, with Unbreakable Enterprise Kernel 4.14.35-2025.402.2.1.el7uek.x86_64
3 : Oracle Linux Server 7.9, with Linux 3.10.0-1160.42.2.el7.x86_64
4 : Oracle Linux Server 7.9, with Linux 3.10.0-1160.6.1.el7.x86_64
5 : Oracle Linux Server 7.9, with Linux 3.10.0-1127.el7.x86_64
6 : Oracle Linux Server 7.9, with Linux 0-rescue-eae8afff46974c6baababee750bdbc6b
[root@oracle ~]#
KERNEL EM USO SEM PROBLEMA

[root@oracle ~]# uname -r
4.14.35-2025.402.2.1.el7uek.x86_64
[root@oracle ~]#
Print do Erro no boot

Buckminster
(usa Debian)

Enviado em 24/09/2021 - 14:57h

Quer dizer então que o Unbreakable quebrou?

Out of memory é falta de memória, o kernel não consegue "subir" porque não tem memória para ele, alguns processos deixaram somente uma vaga lembrança para o kernel. Talvez alguns processos, ao inicializar, estão consumindo muita memória RAM ou talvez a máquina tenha pouca memória RAM. Às vezes não é exatamente pouca memória RAM, mas algum processo que está com erro.

Pela mensagem dá para ver que o journal está consumindo muita memória e também o plymouth. O plymouth é o programa responsável por aquela tela em movimento que você vê logo que liga o computador.
Então o kernel "mata" esses processos glutões de memória utilizando o Assassino de Processos.
E o kernel, basicamente, escolhe quem trucidar pela função badness que leva em consideração 3 pontos:
Processos que estão em execução há muito tempo
Processos iniciados por superusuários
Processo com acesso direto ao hardware

O kernel irá aguardar algum tempo para ver se memória suficiente foi liberada matando um processo. Se memória suficiente não for liberada, os OOM-kills continuarão até que memória suficiente seja liberada ou até que não haja mais processos candidatos a serem eliminados. Se o kernel fica sem memória e não consegue encontrar um processo candidato para matar, ele entra em pânico (grita, se desespera) e dá a mensagem OOM.

Bom, para resolver isso, já que está conseguindo entrar no sistema por outro kernel, tente dar um

# grub2-mkconfig -o /boot/grub2/grub.cfg
# yum update

Também, dentro do sistema, veja os logs:
# cat /var/log/messages* | grep "Out of memory"
# free -lm

Caso não resolver, desabilite o OOM temporariamente e veja se entra no kernel:
# sysctl vm.panic_on_oom=1

Coloque 1. Os valores são 0, 1 e 2. Zero é o padrão. Com zero acontece o que tu está vendo, com 1 o kernel mata os processos e força a entrada dele, com 2 dá kernel panic direto. Veja os logs, veja se tem RAM física suficiente, Swap, etc.
Depois coloque zero de novo.

https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-oom-killer.html


________________________________________________
Always listen the Buck!
Sanou tua dúvida, resolveu teu problema?
Então marque como Resolvido e escolha a Melhor Resposta.

leandropscardua
(usa Ubuntu)

Enviado em 24/09/2021 - 16:19h

Siga a sugestão: systemctl status systemd-journald.service
e veja como está o espaço dos logs
du -hS /var/log/journal/*
df

fsantanajr
(usa Outra)

Enviado em 28/09/2021 - 16:30h

Olá Buckminster.

Agradeço a sua resposta. Irei seguir a sua recomendação e respondo em breve.

Pois é o Unbreakable quebrou, e tenho 2 servidores na mesma situação, ambos após o yum update e o reboot.


Obrigado.

fsantanajr
(usa Outra)

Enviado em 29/09/2021 - 05:45h

Olá leandropscardua.

Obrigado pela sua ajuda. Em breve retorno apos os testes.

Espaço para log tem... e muito.

fsantanajr
(usa Outra)

Enviado em 07/10/2021 - 18:31h

Olá Buckminster.
Fiz as configurações recomendadas, mas ainda assim ao reinicia o linux quando ele tenta iniciar pelo kernel 5.X o erro anexo é apresentado.

Buckminster
(usa Debian)

Enviado em 08/10/2021 - 23:51h

Quanto de memória RAM tem nessa máquina?


________________________________________________
Always listen the Buck!
Sanou tua dúvida, resolveu teu problema?
Então marque como Resolvido e escolha a Melhor Resposta.

fsantanajr
(usa Outra)

Enviado em 14/10/2021 - 19:21h

Tem 16GB.

Buckminster
(usa Debian)

Enviado em 15/10/2021 - 22:53h

Tente o seguinte, entre pelo kernel 4.14 e execute:
$ df /boot
e veja se está 100% ocupado (uso).
Também pode executar:
$ sudo du -sh /boot
para ver o tamanho do diretório /boot.

Entre no arquivo /boot e apague manualmente (rm -rf 3.10...) os kernel mais antigos e deixe somente o 4.14 e o 5.4.
$ cd /boot
$ ls
Veja os arquivos e deixe somente os arquivos de initrd.img, config, system.map e vmlinuz do 5.4 e do 4.14.
Dos outros pode apagar todos. Não vá apagar o grub, se tiver. Apague somente os arquivos relativos aos kernel antigos deixando os do 5.4 e 4.14.
Exemplo:
$ rm -rf *-3.10.0-*
Ou apague um por um.

Daí reinicie e veja se resolve o problema.
Caso tenha resolvido então é porque o /boot está pequeno e quando numa atualização vier um kernel novo ou uma atualização de kernel poderá acontecer outra vez, mas daí tu já sabe.... ou aumente o tamanho do diretório /boot, caso for isso.


________________________________________________
Always listen the Buck!
Sanou tua dúvida, resolveu teu problema?
Então marque como Resolvido e escolha a Melhor Resposta.

fsantanajr
(usa Outra)

Enviado em 19/10/2021 - 16:57h

Boa tarde Buckminster.
Cara aconteceu tanta coisa.. Fui remover o kernel mais atual com problema, reiniciei o servidor e não subiu mais. Consegui iniciar pelo kernel em modo de recuperação, ai migrei o banco para outro OL.

Sobre o tamanho do /boot, sempre faço com 1GB. No servidor atual está com 220MB de uso.

Tenho uma suspeita, será que o virtualizador iria interferir? Pois tenho outras vm's rodando no esxi 6.5 e nunca tive estes problemas. Esta vm em questão está rodando no proxmox.



Agradeço a sua ajuda, muito obrigado a todos que interagiram com o post.

Valew.