Servidor parou do nada e agora não sobe!

[RevendaHost]

  Em 27/01/2017 em 20:11, Jorge Marcelino disse:

Amigo, no modo rescue você desativa.

Expand  

Ai que está... mesmo no modo rescue nada funciona, nem mesmo montando as partições... até mesmo o diretório /scripts apesar de listado não é acessado. Mudo permissão, tento deletar o /tmp /tmpdsk e nada.

[Jorge Marcelino]

  Em 27/01/2017 em 20:14, RevendaHost disse:

Ai que está... mesmo no modo rescue nada funciona, nem mesmo montando as partições... até mesmo o diretório /scripts apesar de listado não é acessado. Mudo permissão, tento deletar o /tmp /tmpdsk e nada.

Expand  

E pelo VNC? Está na OVH?

[RevendaHost]

  Em 27/01/2017 em 20:15, Jorge Marcelino disse:

E pelo VNC? Está na OVH?

Expand  

Sim na OVH. No caso modo rescue e por ssh. Por VNC piorou não tem como fazer nada, nem pular o problema para continuar o boot.

  Em 27/01/2017 em 20:15, brunowebmaster disse:

Amigo...

Voce deve deletar "/usr/tmp.secure" e "/usr/tmp.secure.cpback"

Expand  

Se existissem com certeza eu já teria feito isso. rsrs

 O fato é que o servidor do cliente funcionando normalmente, vai e do nada para e dá essa bagunça toda. Estou achando que tem relação com o DC.

[RevendaHost]

  Em 27/01/2017 em 20:20, brunowebmaster disse:

Voce ta tentando excluir esses diretorios usando o mode rescue? Se sim! Tem q montar a partição.

Caso contrário, um simples mkdir resolve. 

Expand  

rsrs

Montar a partição eu sei disso e logicamente que foi feito (isso é básico), agora não tem os diretórios e se criar ele permanece no problema... rsrsr

[RobertSP]

veja se seu /tmp não está lotado, geralmente ocorre com quem usa proxy reverso via plugins como engintron e nginxcp sem configurar individualmente a necessidade da máquina.

 

df -h
df -i

instale e use tmpwatch

/usr/sbin/tmpwatch --verbose --mtime --all 1 /tmp

[RevendaHost]

Só para informar, somente ontem a noite consegui solucionar o problema depois de muitos testes e até informações obtidas (com muito custo) no suporte do cpanel. No final nem era algo tão complicado a questão maior era as limitações do modo rescue na OVH, foi ai que o cpanel ajudou com algumas "gambiarras" para quebrar essas limitações e enfim eu conseguir ter mais acesso e resolver.

Mais tarde vou descrever o que foi feito e posto aqui, pois certamente algum dia alguém pode precisar usar o modo rescue na OVH e ficar "travado" em alguns pontos assim como eu fiquei.

[Jorge Marcelino]

@RevendaHost Mas o problema mesmo era no securetmp?

[RevendaHost]

  Em 28/01/2017 em 13:43, Jorge Marcelino disse:

@RevendaHost Mas o problema mesmo era no securetmp?

Expand  

Também. Porém o maior está relacionado com uma falha de hardware no servidor ou sistema da OVH, pois o boot ficava em uma espécie de loop, toda a vez que tentava pular a execução do securtemp o servidor na verdade estava dando um reboot, inclusive o próprio painel da OVH também estava apresentando várias falhas se tentasse dar reboot por lá, tinha vezes que nem deixava retornava uma mensagem dizendo que não havia permissão para fazer isso. Então foi comunicado ao suporte os problemas por parte deles e sempre informavam que seria avaliado mas no final nunca encontravam problema algum sendo que até mesmo o log do sistema deles apontava os problemas.

O fato é que o servidor está online novamente, porém horrível o desempenho, muito lento e o link de rede abaixo de 10mb, o que levou o cliente a contratar outro servidor e agora temos que migrar as contas.

[Jorge Marcelino]

@RevendaHost Você contratou em outro DC? O ideal seria ter um suporte ativo, assim resolveria seu problema muito mais rápido.