¿Cómo depurar si los reinicios son causados ​​por software o hardware?

Una nueva versión de Linux debian 2.6.32-5-amd64 # 1 SMP dom 23 de septiembre 10:07:46 UTC 2012 x86_64 El server GNU / Linux sufre numerosos reinicios.

La salida ' last -x ' muestra:

 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) 

Salida de la order ' top ' less de 0.1 segundos antes de que ocurriera un locking / reinicio:

 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 

La salida de ' Sensors ' en el minuto 16 muestra:

 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 

Actualización # 2 :

  • Cuando se ejecuta top el problema ocurre a menudo en el minuto 16 del time de actividad.
  • Al tener less carga conectada (60 en lugar de 74 unidades SATA) a la fuente de alimentación Corsair 1050HX, el problema nunca ocurre.
  • Con 74 unidades SATA conectadas, en el minuto 14, ¿"watts up?" el medidor de repente comienza a medir un mayor valor de consumo de energía: 435 vatios en lugar de 326 vatios.
  • El aumento repentino de potencia en el minuto 14 también ocurre en otras versiones del kernel bpo.3 y bpo.4 donde los modules de almacenamiento no se cargan en el núcleo (no / dev / sdb etc.)

Actualización n. ° 3 : todas las unidades no están particionadas, no formateadas y no montadas, excepto para una unidad de arranque.

Actualización n. ° 4 : el problema por el que las unidades HDS5C de Hitachi / Toshiba están comenzando a consumir más considerablemente: 5,34 W en lugar de 3,5 W sin actividad de lectura / escritura. Más potencia después de 15 minutos no parece estar relacionado con SO cat /proc/diskstats | grep " sd" cat /proc/diskstats | grep " sd" devuelve 224 sectores de lectura y 0 sectores escritos después del inicio, y ese número permanece idéntico cuando el consumo de energía comienza a boost.

La pregunta es cómo saber si estos reinicios son causados ​​por:

  • Software
  • Hardware (por ejemplo, una situación corta pateando la protección de sobre stream en la fuente de alimentación)?

Solutions Collecting From Web of "¿Cómo depurar si los reinicios son causados ​​por software o hardware?"

Monitoreando más de cerca el sistema es su consumo de energía usando un "watts up?" El medidor de Watt lleva a una creencia más fuerte de que estos reinicios fueron causados ​​por una protección de sobre stream (OCP) en la fuente de alimentación que se activa.

Preguntar por qué el consumo de energía aumentó 15 minutos después del arranque, una respuesta incorrecta del server indica que 15 minutos después del inicio, las 74 unidades podrían comenzar a ejecutar sus testings automáticas sin connection SMART (autocomprobación, análisis e información de las unidades de disco duro) en al mismo time.

El siguiente bash fue deshabilitar la ejecución de testings automáticas sin connection con: smartctl --offlineauto=off /dev/sdx . Como ahora no hay más picos de consumo de energía ni reinicios durante 20 horas, una conclusión preliminar es que la causa es su configuration para ejecutar testings SMART periódicas sin connection.

En primer lugar, 72 discos duros son muchos (la máquina más grande que tengo tiene solo 24 … y tiene 1200W de suministros) Espero que estés usando un centrifugado escalonado.

Probablemente esté viendo que las unidades inician una recostackción de datos fuera de línea. Eso explicaría el aumento en el consumo de energía. También significa que si realmente usaras las unidades, probablemente impulsarías el consumo de energía al less igual de alto.

La hoja de especificaciones de su unidad indica un pico de 2 A en el riel de 12V. Su fuente de alimentación dice que puede hacer 87.5A en el riel de 12V. Entonces podrías superarlo fácilmente, especialmente porque otros componentes quieren algo de eso. Es posible que desee get un voltímetro (y el medidor actual si es posible) en ese carril, para ver si eso está sucediendo.

Voy a seguir adelante y adivinar que la respuesta es "sí". Se está ejecutando con un suministro pequeño en comparación con la cantidad de unidades. Por ejemplo, un generador de sistemas que utilizamos hace un JBOD de 45 unidades con 1400W de suministros , y usted todavía tiene más unidades y una computadora. Por supuesto, ese JBOD probablemente esté diseñado para unidades SAS de 15K. Pero tienes 27 unidades adicionales.

Depuración de un locking de software (que probablemente no sea así)

Lo principal que desea probar y encontrar un locking de software es get los loggings del kernel hasta el último segundo posible. Su mejor opción es, si tiene un serial port, conectar otra máquina y usar la console serie (agregue console = / dev / ttyS0,57600 a la command-line del kernel). Su segunda mejor opción es usar netconsole, que puede configurar fácilmente una vez que la máquina se inicia (pero antes de que transcurran los 16 minutos):

Primero, en alguna otra máquina, ejecute nc -l -u -p 1234 . Luego, en la máquina que modprobe netconsole netconsole=@/eth0,1234@some-ip/ , modprobe netconsole netconsole=@/eth0,1234@some-ip/ . Debería ver algunos posts de console inmediatamente en la window de netcat:

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

Tus marcas de time serán mucho más bajas, por supuesto.

Según su salida de last -x , parece reiniciarse cada 17-18 minutos, por lo que primero debe verificar, ¿hay algún script o cron configurado para reiniciar o no? Si no, lee a continuación.

Error relacionado con el hardware que puede verificar en dmesg | tail loggings relacionados con la dmesg | tail o el software que puede encontrar en los loggings de esa aplicación en particular que está ejecutando en su server usualmente tail -f /var/log/messages o tail -f /var/log/syslog (basado en debian).

Y si quiere verificar rápidamente si hay problemas de software o de hardware, entonces debe verificar 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. 

enter image description here

También debe verificar el valor de% wa en la parte superior, en caso de que haya un problema con su disco duro, entonces este valor boostá. Entonces puede verificar usando hdparam -T /dev/sdx y otras herramientas. Pero esto no es definitivo, puede haber muchas forms de verificar lo mismo.

Verifique los / var / log / posts

Si no ve el apagado o init 6, la causa más probable es el hardware. De lo contrario, algún usuario reiniciará el reinicio.

Debe verificar la temperatura de la CPU, puede verificar en syslog usando el siguiente command: – grep 'temperature' /var/log/syslog si la salida del command anterior está en blanco, entonces tiene que instalar el package lm-sensors y ejecutar los sudo sensors-detect elija SÍ a todas las preguntas SI / NO. Al final de la detección de sensores, se mostrará una list de los modules que se deben cargar. Escriba "sí" para que detecte sensores inserte esos modules en / etc / modules, o edite / etc / modules usted mismo. A continuación, ejecute sudo service module-init-tools restart Esto leerá los cambios que realizó en / etc / modules en el paso 3 e insertá los nuevos modules en el kernel. A continuación, debe probar que lm-sensors funciona correctamente. Ejecute el command de sensors y verifique si es posible publicar salida. Creo que necesita ejecutar este command después de 15 minutos de time de inicio del sistema, ya que cada reinicio entre 17-18.