Como depurar se as reinicializações são causadas por software ou hardware?

Question

Um recém-compilado Linux debian 2.6.32-5-amd64 # 1 SMP Dom Set 23 10:07:46 UTC 2012 x86_64 O servidor GNU / Linux sofre diversas reinicializações.

A saída " last -x "

mostra:

root     pts/0        192.168.254.11   Sat Dec 15 13:13   still logged in   
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 13:10 - 13:17  (00:06)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 13:10 - 13:17  (00:06)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:53 - 13:10  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:53 - 13:17  (00:23)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:36 - 12:53  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:36 - 13:17  (00:40)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:19 - 12:36  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:19 - 13:17  (00:57)    
root     pts/0        192.168.254.11   Sat Dec 15 12:04 - crash  (00:14)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:01 - 12:19  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:01 - 13:17  (01:15)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 11:44 - 12:01  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 11:44 - 13:17  (01:32)    
root     pts/0        192.168.254.11   Sat Dec 15 11:36 - crash  (00:08)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 11:26 - 11:44  (00:18)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 11:26 - 13:17  (01:50)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 11:08 - 11:26  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 11:08 - 13:17  (02:08)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 10:51 - 11:08  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 10:51 - 13:17  (02:25)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 10:34 - 10:51  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 10:34 - 13:17  (02:42)    
root     pts/0        192.168.254.11   Sat Dec 15 02:41 - crash  (07:53)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 02:32 - 10:34  (08:02)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 02:32 - 13:17  (10:45)    
runlevel (to lvl 0)   2.6.32-5-amd64   Sat Dec 15 02:12 - 02:32  (00:19)

Saída do comando ' top ' menos de 0,1 segundo antes de ocorrer uma falha / reinicialização:

top - 15:14:04 up 16 min,  2 users,  load average: 0.00, 0.00, 0.01
Tasks: 163 total,   1 running, 162 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  8.3%sy,  0.0%ni, 91.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8191048k total,    87356k used,  8103692k free,     2432k buffers
Swap:        0k total,        0k used,        0k free,    20120k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                       
 2296 root      20   0 19072 1432 1032 R    9  0.0   0:10.25 top                                                                                                            
    1 root      20   0  8356  820  684 S    0  0.0   0:00.79 init                                                                                                           
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd                                                                                                       
    3 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0                                                                                                    
    4 root      20   0     0    0    0 S    0  0.0   0:00.03 ksoftirqd/0                                                                                                    
    5 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0                                                                                                     
    6 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/1                                                                                                    
    7 root      20   0     0    0    0 S    0  0.0   0:00.00 ksoftirqd/1                                                                                                    
    8 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/1                                                                                                     
    9 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/2                                                                       

A saída " Sensors " no minuto 16 mostra:

temp1:       +37.0 C  (high = +60.0 C, hyst = +55.0 C)  sensor = thermistor
temp2:       +75.0 C  (high = +95.0 C, hyst = +92.0 C)  sensor = diode
temp3:       +32.0 C  (high = +75.0 C, hyst = +70.0 C)  sensor = thermistor

Atualização nº 2 :

• Ao executar top , o problema ocorre com frequência no 16º minuto do tempo de atividade.
• Ao ter menos carga acoplada (60 em vez de 74 unidades SATA) ao PSU 1050HX da Corsair, o problema nunca ocorre.
• Tendo 74 drives SATA conectados, no minuto 14 o "watts up?" O medidor começa a medir um aumento no consumo de energia: 435 Watt em vez de 326 Watt.
• O aumento súbito de energia no minuto 14 também ocorre em outras versões do kernel bpo.3 e bpo.4, em que os módulos de armazenamento não são carregados no kernel (no / dev / sdb, etc.)

Atualização nº 3 : todas as unidades não são particionadas, não formatadas e não montadas, exceto por uma unidade de inicialização.

Atualização # 4 : o problema onde as unidades Hitachi / Toshiba HDS5C estão começando a consumir mais consideravelmente - 5.34W em vez de 3.5W sem nenhuma atividade de leitura / gravação - mais energia após 15 minutos não parece SO (Software) relacionado porque cat /proc/diskstats | grep " sd" retorna 224 setores lidos e 0 setores escritos após a inicialização, e esse número permanece idêntico quando o consumo de energia começa a aumentar.

A questão é como descobrir se essas reinicializações são causadas por:

• Software
• Hardware (por exemplo, uma situação curta na proteção contra sobrecarga de corrente na fonte de alimentação) ?

Answer 1

Monitorando mais de perto o sistema, o consumo de energia é "watts up"? O medidor de Watt leva a uma crença mais strong de que essas reinicializações foram causadas por uma proteção contra sobrecarga de corrente (OCP) na fonte de alimentação que entra em ação.

Perguntando por que o aumento no consumo de energia ocorreu 15 minutos após a inicialização, leva a uma resposta de falha de servidor que, 15 minutos após a inicialização, todas as 74 unidades podem começar a executar seu S.M.A.R.T. (Tecnologia de monitoração automática, análise e geração de relatórios de unidades de disco rígido) testa ao mesmo tempo.

A próxima tentativa foi desabilitar a execução de testes offline automáticos com: smartctl --offlineauto=off /dev/sdx . Como agora não há mais picos de consumo de energia nem reinicia por já 20 horas, uma conclusão preliminar é que a unidade sua configuração para executar S.M.A.R.T. testes é a causa.

    

Answer 2

Primeiramente, 72 discos rígidos são muito (a maior máquina que tenho é de apenas 24 ... e tem suprimentos de 1200W) Espero que você esteja usando spin-ups escalonados.

Você provavelmente está vendo as unidades iniciarem uma coleta de dados off-line. Isso explicaria o aumento no uso de energia. Isso também significa que, se você realmente usasse as unidades, provavelmente o consumo de energia seria pelo menos tão alto.

A folha de especificações do inversor indica um pico de 2A no trilho de 12V. Sua fonte de alimentação diz que pode fazer 87,5A no trilho de 12V. Então você pode facilmente exceder isso, especialmente porque outros componentes querem um pouco disso. Você pode querer obter um voltímetro (e um medidor de corrente, se possível) naquele trilho, para ver se isso está acontecendo.

Eu vou em frente e acho que a resposta é "sim". Você está correndo com um pequeno suprimento comparado ao número de drives. Por exemplo, um construtor de sistemas que utilizamos faz um JBOD de 45 drives com 1400W de capacidade / a>, e você tem mais unidades ainda e um computador também. Obviamente, esse JBOD provavelmente é especificado para unidades SAS de 15K. Mas você tem 27 unidades extras.

Depurando uma falha de software (que provavelmente não é)

A principal coisa que você quer tentar encontrar uma falha de software é obter os logs do kernel até o último segundo possível. Sua melhor aposta é, se você tiver uma porta serial, conectar outra máquina e usar o console serial (adicione console = / dev / ttyS0,57600 à linha de comando do kernel). Seu segundo melhor é usar o netconsole, que você pode configurar facilmente quando a máquina é inicializada (mas antes de 16 minutos):

Primeiro, em alguma outra máquina, execute nc -l -u -p 1234 . Em seguida, na máquina sempre em falha, modprobe netconsole netconsole=@/eth0,1234@some-ip/ . Você deve ver algumas mensagens do console imediatamente na janela do netcat:

[508073.196581] console [netcon0] enabled
[508073.197026] netconsole: network logging started

Seus timestamps serão muito menores, é claro.

    

Answer 3

De acordo com a sua saída de last -x , parece reiniciar a cada 17-18 minutos, então você precisa primeiro verificar, existe algum script ou cron está configurado para reiniciar ou não? Se não, leia abaixo.

Erro relacionado a hardware, você pode verificar em dmesg | tail ou logs relacionados a software que você pode encontrar nos logs daquele aplicativo em particular que você está executando em seu servidor geralmente tail -f /var/log/messages ou tail -f /var/log/syslog (baseado no debian).

E se você quiser verificar rapidamente se há problema de software ou problema de hardware, verifique top .

hi  --  Hardware IRQ
          The amount of time the CPU has been servicing hardware interrupts.

si  --  Software Interrupts
          The amount of time the CPU has been servicing software interrupts.

Além disso, você deve verificar o valor de% wa no topo, no caso, se houver problema com o seu hdd, esse valor aumentará. Então você pode verificar usando hdparam -T /dev/sdx e outras ferramentas. Mas isso não é definitivo, pode haver muita maneira de verificar o mesmo.

    

Answer 4

Verifique o / var / log / messages

Se você não vê nenhum shutdown ou init 6, a causa mais provável é o hardware. Caso contrário, será reinicializado por algum usuário.

    

Answer 5

Você tem que verificar a temperatura da CPU, você pode verificar no syslog usando o comando abaixo: - %código% Se a saída do comando acima estiver em branco, será necessário instalar o pacote grep 'temperature' /var/log/syslog e executar lm-sensors escolha YES para todas as perguntas SIM / não. No final da detecção de sensores, será exibida uma lista de módulos que precisam ser carregados. Digite "yes" para que os sensores detectem esses módulos em / etc / modules, ou edite o / etc / modules você mesmo. Em seguida, execute sudo sensors-detect Isso lerá as alterações feitas em / etc / modules na etapa 3 e inserirá os novos módulos no kernel. Em seguida, você deve testar se os sensores de lm funcionam corretamente. Execute o comando sudo service module-init-tools restart e verifique se possível pós-saída. Eu acho que você precisa executar este comando após 15 minutos do seu tempo de inicialização do sistema, porque cada reinicialização entre 17-18.