/ proc / sys / kernel / hung_task_timeout_secs

4

Estou construindo um servidor do CentOS 6.2 em um cluster do Hyper-V e atingi um grande problema. A configuração atual é esta:

Sistema operacional: CentOS 6.2. Instalação mínima do servidor O software instalado inclui:

  • Drivers de integração do Hyper-V Linux
  • Webmin
  • Apache 2
  • MySQL 5. *
  • php 5 com acelerador APC php
  • o servidor web está executando o Moodle (se fizer alguma diferença em mencioná-lo)

A última coisa que eu instalei foi o "Drivers de integração do Hyper-V Linux" após o qual ... alguns dias depois todo o sistema operacional foi travado com erro "tarefa bloqueada por mais de 120 segundos" descendo o console. Eu agora acho que esse erro faz com que ele fique feio ao longo de um tempo de execução prolongado e seja acionado por meio de um comando de atualização do yum sinalizando logo após o segundo download.

Eutenteifsckcomosugeridoemoutrosfóruns,massemsucesso.AmaioriadosoutrosfórunsindicamproblemasdehardwarecomoacausaquenãopodecaberaquicomoclusterdoHyper-V(atualmenteexecutandoumadúziadeserviçosdealtademandasemproblemas)

EDIT:(deveriatermencionadoissopelaprimeiravez)esteerroéaúltimacoisaquevejoantesdetodookerneltravar.depoisdisso,aúnicamaneiradeconsertá-loéreinicializaramáquinavirtual.

Qualquerajudapararesolveroudiagnosticaroproblemaémuitoapreciada.

Obrigado(antecipadamente)

UPDATE1:

OK,graveescalaçãoaqui.Euagoratenho2outrasmáquinasLinuxdomesmoclustercomproblemarelacionadoetodaselascaemaomesmotempo.EutenhoumservidorUbuntureclamandodeumstatus:{DRDY}eumsegundoservidorCentOS6.2reclamamdomesmoerroqueoprimeiroeoprimeiroservidorfalhoudeumanovamaneira...

ErroDRDYdoUbuntu

O primeiro ataque do kernel do CentOS

UPDATE 2: OK, conseguimos o cluster fixo, mas o problema ainda persistia com as duas VMs do CentOS. Eu corrijo o primeiro problema do centOS movendo-o para o Un-clusterd Hyper-V e colocando na lista negra todos os Linux Integration Drivers seguidos de desinstalá-los completamente. Parece que os drivers de integração do Linux para o computador convidado ao longo dos problemas com o sistema em cluster causam esse problema. a segunda máquina do CentOS não tem tanta sorte ... mesmo que eu a tenha transferido para o Hyper-V não agrupado e colocado na lista negra dos drivers, ela ainda travou infelizmente bem no meio da desinstalação do driver de integração do Linux. agora eu tenho a grande questão do pacote de driver mostrando no banco de dados do rpm e sendo apenas metade dele.

Pergunta: existe uma maneira de remover completamente estes drivers sem usar o rpm ou o yum agora ambos reclamam que ele está lá e não está lá e não consegue removê-lo e tentar fazer algo muito pesado como o rpm eo yum fazem com que todo o sistema colidir novamente. Nesse ritmo, posso acabar reconstruindo-o completamente, mas preciso estabilizá-lo em breve, pois ele hospeda serviços essenciais.

A RESPOSTA

OK, minha última VM CentOS problemática foi corrigida. para remover o Linux Integration Driver e estabilizar o sistema, fiz o seguinte:

  1. Baixei um Live CD do CentOS e inicializei-o na VM defeituosa.
  2. Eu criei uma nova pasta com

    $mkdir /mnt/OS
    
  3. então montou o sistema de arquivos raiz do sistema operacional defeituoso (que no meu caso é sda2)

    $mount /dev/sda2 /mnt/OS
    
  4. Eu, então, montei a partição de inicialização (que no meu caso é sda1)

    $mount /dev/sda1 /mnt/OS/boot
    
  5. Eu então chroot para a falha OS

    $chroot /mnt/OS
    
  6. e depois executou o comando rpm remove package (garantindo que todas as duplicatas foram removidas no processo)

    $rpm -e --allmatches kmod-microsoft-hyper-v
    
  7. esse processo pode demorar um pouco, mas, depois de concluído, eu poderia reinicializar a VM e meu sistema estava funcionando sem os drivers de integração, mas agora ele permite atualizações de pacote sem travar.

Depois disso, acho que vou deixar os drivers do Hyper-V fora do mix até que eu esteja confortável que eles funcionem e sejam estáveis.

    
por Balasarius 20.08.2012 / 17:18

1 resposta

1

O seu kernel ativou esse recurso de detecção de bloco de tarefas. Na maioria dos casos, isso deve ser bom, já que não é um bloqueio real. Você pode simplesmente usar o comando sugerido acima para desabilitar isso.

Eu já encontrei um problema parecido antes. No kernel, se você usar down (semáforo) ao invés de down_interruptable (semáforo) para esperar um semáforo e este semáforo não estiver ativo em 120 segundos. Terá esse INFO impresso. Na verdade, é bom ter o semáforo liberado em 120 segundos.

Se as coisas funcionam bem, exceto esta informação, basta desabilitar isso por eco 0.

    
por 21.08.2012 / 10:35