CentOS travando numa VMware [RESOLVIDO]

tiagopduarte26
(usa FreeBSD)

Enviado em 04/10/2021 - 14:17h

Sim, quando atualizei validei tudo e a máquina esta até o momento rodando super bem.
Para análise final, gostaria de saber qual a maneira mais segura de eu rodar um fsck no Linux. Sei que no Windows é bom fazermos no boot, no Linux também seria o mais recomendável?
Existe um comando que eu possa fazer para ele rodar no boot? pois o S.O trava sem avisar e ficamos sem acesso algum. Quanto menos recurso do S.O usarmos acredito que vai evitar dores de cabeça na hora desta análise.

removido
(usa Nenhuma)

Enviado em 04/10/2021 - 17:08h

Atualização de kernel no CentOS7 exige que a VM seja reiniciada. Recomendo estudo sobre geração e análise de dump, em casos de travamentos inesperados (sem respostas satisfatórias nos logs).

Em relação ao fsck veja como está seu fstab.

A sexta coluna é a opção fsck. O utilitário verifica esse número para determinar em que ordem os sistemas de arquivos devem ser checados. Se seu valor for zero o sistema não será checado.

tiagopduarte26
(usa FreeBSD)

Enviado em 04/10/2021 - 17:47h

Entao... eu pesquisei hoje a tarde a respeito. Diz que tudo que precisa ser feito é criar um arquivo usando "touch /forcefsck". Testei mas nao fez nada.

No meu fstab tenho isso em anexo. Vou dar uma pesquisada sobre como ele funciona.

leandropscardua
(usa Ubuntu)

Enviado em 04/10/2021 - 22:28h

Segundo a imagem do fstab nenhum sistema de arquivo está sendo checado durante o boot. O artigo seguinte pode auxiliar
https://linuxconfig.org/how-to-force-fsck-to-check-filesystem-after-system-reboot-on-linux

tiagopduarte26
(usa FreeBSD)

Enviado em 06/10/2021 - 09:44h

Bom dia,
Desculpem a demora em responder.
Então, esse tópico eu ja tinha lido e tinha feito exatamente o que comentei acima. Mas nao entra na tela para analisar o disco.

tiagopduarte26
(usa FreeBSD)

Enviado em 06/10/2021 - 17:50h

Acabou de travar.
Estou pensando em fazer o seguinte:
1 - desmontar unidade
2- executar o comando de reparo via terminal com o S.O aberto.

Isso é seguro de fazer? considerando que o volume é de 4TB?

removido
(usa Nenhuma)

Enviado em 06/10/2021 - 17:52h

Você tem que trabalhar em identificar o motivo do travamento. Ative a geração do dump e monitore o consumo dos recursos.

tiagopduarte26
(usa FreeBSD)

Enviado em 07/10/2021 - 11:06h

Sou bem leigo, onde eu ativo isso, ou terias algum link deste processo? Eu comentei sobre rodar o fsck justamente pq vocês orientaram ver isso, conforme print que enviei mais acima. Como é um servidor que não pode parar preciso urgente tomar uma ação para resolver este caso. Estou bem preocupado :(

tiagopduarte26
(usa FreeBSD)

Enviado em 07/10/2021 - 14:47h

Pesquisei a respeito. Seria este processo:
https://www.linuxtechi.com/how-to-enable-kdump-on-rhel-7-and-centos-7/
?
- Minha máquina de testes esta rodando perfeitamente
- Quando meu servidor oficial para, ela ainda esta la na tela do LINUX, nao apresenta nenhima mensagem de erro e o ping continua rodando. O SMB para e não consigo acessar meu storage (que esta como SMB).

Nestas condições acredito que o Storage seja o problema certo? Por isso queria tentar um fsck direto nele (mas queria fazer da maneira mais segura). Acredito que desativar a rede e o SMB vai evitar o risco de travar tbm certo?

Neste cenário o dump me daria a resposta?

tiagopduarte26
(usa FreeBSD)

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

Segui o passo a passo para tentar fazer um fsck no disco. Mas nao funciona, o mais estranho é que não consigo ver o arquivo de log do fsck tbm. Eu confirmei a criação do arquivo dando um LS, e mudei os últimos dígitos do print ali de 0 para 1.
Eu tentei mais outras 2 formas, usando tune2fs e alterando o arquivo do grub incluindo o parâmetro: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash fsck.mode=force"
Não sei mais o que fazer :(. Travou 2x hoje. Como já expliquei dentro do Storage esta tudo ok. Acreditamos que o problema esteja no volume dos arquivos e a verificação com o fsck deve corrigir.
Acredito que quando temos um volume muito grande de arquivos (mais de 4 TB) com arquivos entre 10 a 20k o ideal seja ter um sistema em nuvem né?
Preciso tentar alguma solução neste fim de semana :(

tiagopduarte26
(usa FreeBSD)

Enviado em 08/10/2021 - 19:04h

Amigo, veja se isso já seria o processo dump rodando:

Ao logar como root, ele pede para executar um comando (abrt-list, algo assim)
O retorno sai algo assim:

id ************************************
reason: general protection fault: 0000[#1] SMP
time : ------
uid: 0(root)
count: 1
Directory: /var/spool/abrt/vmcore...
cd /var/spool/abrt/vmcore...

Lá dentro tem um arquivo vmcore-dmesg.txt. Ao executar um cat consigo ver umas falhas que seguem no print:
Tentei pesquisar exatamente aquele erro, e alguns sites indicam rodar o DVD do Linux e entrar em modo de recuperação para analisar a unidade. Já validei isso em ambiente de teste (com um disco simples de 10 GB).
Seria melhor utilizando o DVD ou direto com o S.O ligado desmontando a Unidade de 4 TB?

tiagopduarte26
(usa FreeBSD)

Enviado em 08/10/2021 - 19:13h

Complementando acima, acabei de perceber neste loga linha do "General Protection fault: 0000[#1] SMP
Me desculpem meu jeito leigo, mas poderiam me explicar se é aqui que esta o problema, se possível também me passarem um bom link para eu estudar análise de LOGS.

Lendo as linhas ali, ele comenta sobre o vmxnet3 (recurso do Vmware ESXI que ativamos para usar rede 10GB).
É possível que a falha esteja aqui e eu esteja sofrendo com o Storage por besteira :(?

Desculpem postar tantas vezes sem resposta, mas preciso tomar uma ação ainda este fim de semana.
Desde já agradeço.