Servidor reiniciando sozinho

[Leo Amarante]

Olá pessoal, recentemente adquiri um servidor que veio com Almalinux 8.10, converti para CloudLinux e instalei cPanel. Após dois dias constatei pequenas quedas durante o dia e monitorando mais de perto identifiquei que não eram quedas e sim o servidor estava reiniciando sozinho em média a cada 3 horas.

Já revisei tudo e não consegui identificar o problema, do lado do hardware o suporte do DC informa que está tudo ok e sem falhas na parte elétrica ou aquecimento, além disse revisaram a BIOS e garantiram que não há nada errado.

Algum colega já passou por algo semelhante ou pode me dar um norte do que pode estar ocorrendo? segue log durante o último reboot:

 

Nov 30 00:35:01 zeta systemd[89826]: Started Mark boot as successful after the user session has run 2 minutes.
Nov 30 00:35:12 zeta systemd[89826]: Stopped Mark boot as successful after the user session has run 2 minutes.
Nov 30 00:40:02 zeta systemd[92954]: Started Mark boot as successful after the user session has run 2 minutes.
Nov 30 00:40:13 zeta systemd[92954]: Stopped Mark boot as successful after the user session has run 2 minutes.
Nov 30 00:44:03 zeta kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-553.16.1.lve.1.el8.x86_64 root=/dev/mapper/almalinux-root ro crashkernel=auto resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap rhgb quiet rootflags=uquota rootflags=uquota systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller cgroup.memory=nokmem
Nov 30 00:44:03 zeta kernel: smpboot: Allowing 8 CPUs, 0 hotplug CPUs
Nov 30 00:44:03 zeta kernel: Booting paravirtualized kernel on bare hardware
Nov 30 00:44:03 zeta kernel: Kernel command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-553.16.1.lve.1.el8.x86_64 root=/dev/mapper/almalinux-root ro crashkernel=auto resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap rhgb quiet rootflags=uquota rootflags=uquota systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller cgroup.memory=nokmem
Nov 30 00:44:03 zeta kernel: smpboot: Estimated ratio of average max frequency by base frequency (times 1024): 1080
Nov 30 00:44:03 zeta kernel: smpboot: CPU0: Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz (family: 0x6, model: 0x3c, stepping: 0x3)
Nov 30 00:44:03 zeta kernel: x86: Booting SMP configuration:
Nov 30 00:44:03 zeta kernel: smpboot: Max logical packages: 1
Nov 30 00:44:03 zeta kernel: smpboot: Total of 8 processors activated (57598.06 BogoMIPS)
Nov 30 00:44:03 zeta kernel: pci 0000:02:00.0: vgaarb: setting as boot VGA device
Nov 30 00:44:03 zeta dracut-cmdline[286]: Using kernel command line parameters: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-553.16.1.lve.1.el8.x86_64 root=/dev/mapper/almalinux-root ro crashkernel=auto resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap rhgb quiet rootflags=uquota rootflags=uquota systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller cgroup.memory=nokmem
Nov 30 00:44:03 zeta systemd[1]: Starting Show Plymouth Boot Screen...
Nov 30 00:44:03 zeta systemd[1]: Started Show Plymouth Boot Screen.
Nov 30 00:44:05 zeta systemd[1]: Mounting /boot...
Nov 30 00:44:05 zeta systemd[1]: Mounted /boot.
Nov 30 00:44:05 zeta kernel: iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS
Nov 30 00:44:05 zeta systemd[1]: Starting Update UTMP about System Boot/Shutdown...
Nov 30 00:44:05 zeta systemd[1]: Started Update UTMP about System Boot/Shutdown.
Nov 30 00:44:11 zeta systemd[1]: Starting cPanel fix quotas on boot...
Nov 30 00:44:11 zeta systemd[1]: Starting Terminate Plymouth Boot Screen...
Nov 30 00:44:11 zeta systemd[1]: Starting Hold until boot process finishes up...
Nov 30 00:44:11 zeta systemd[1]: Started Terminate Plymouth Boot Screen.
Nov 30 00:44:11 zeta systemd[1]: Started Hold until boot process finishes up.
Nov 30 00:44:12 zeta systemd[1]: Started cPanel fix quotas on boot.
Nov 30 00:44:28 zeta systemd[1]: Starting cPanel on Boot service...
Nov 30 00:44:28 zeta systemd[1]: Started cPanel on Boot service.
Nov 30 00:45:01 zeta systemd[5246]: Started Mark boot as successful after the user session has run 2 minutes.
Nov 30 00:45:21 zeta systemd[5246]: Stopped Mark boot as successful after the user session has run 2 minutes.
Nov 30 00:50:02 zeta systemd[9814]: Started Mark boot as successful after the user session has run 2 minutes.
Nov 30 00:50:13 zeta systemd[9814]: Stopped Mark boot as successful after the user session has run 2 minutes.

 

[LucianoZ]

Tem algum painel de IPMI deste servidor? Talvez seja interessante ficar observando os sensores diretamente, mesmo o data center tendo falado que revisou a BIOS.

[barreto]

Eu estava com um servidor na OVH assim e o problema era um dos pentes de memória.. Chegou a testar memória?

[DELTA SERVERS]

Bom dia,

O problema pode estar na RAM. Se o servidor for da OVH, será necessário discutir com eles, já que, mesmo pagando, eles geralmente não aceitam realizar trocas facilmente. Caso precise agendar uma manutenção, agende para as 00:00 horas no horário do data center. Eles informam um horário, mas geralmente é outro.

Esse erro pode ser causado pelo kernel congelando. Execute a atualização do mesmo com o seguinte comando:

dnf install kernel --enablerepo=cl*

Já enfrentamos ambos os casos diversas vezes, e, em 98% das situações, o problema é o kernel do CloudLinux congelando.

[Leo Amarante]

19 horas atrás, LucianoZ disse:

Tem algum painel de IPMI deste servidor? Talvez seja interessante ficar observando os sensores diretamente, mesmo o data center tendo falado que revisou a BIOS.

Pior que não tem, aproveitei uma promoção na ColoCrossing, o suporte é até esforçado mas o painel deles não tem muita altomação. IPMI apenas pagando e caro para habilitar.

3 horas atrás, barreto disse:

Eu estava com um servidor na OVH assim e o problema era um dos pentes de memória.. Chegou a testar memória?

Estou desconfiado, pedi para fazerem um teste com memtester pelo grub, mas não estou muito confiante. Queria resolver para não perder todo trabalho que fiz de configuração e otimização neste server.

7 minutos atrás, DELTA SERVERS disse:

Bom dia,

O problema pode estar na RAM. Se o servidor for da OVH, será necessário discutir com eles, já que, mesmo pagando, eles geralmente não aceitam realizar trocas facilmente. Caso precise agendar uma manutenção, agende para as 00:00 horas no horário do data center. Eles informam um horário, mas geralmente é outro.

Esse erro pode ser causado pelo kernel congelando. Execute a atualização do mesmo com o seguinte comando:

dnf install kernel --enablerepo=cl*

Já enfrentamos ambos os casos diversas vezes, e, em 98% das situações, o problema é o kernel do CloudLinux congelando.

Então, já tive um problema como esse em outro dedicado tempos atrás. Vi em alguns fóruns que esse problema ocorre em alguns modelos de supermicro com Almalinux 8 por conta da versão da BIOS instalada.