3- El disco duro o la controladora han dejado de funcionar temporal o permanentemente
Es la tercera opción que nos queda, y además la resforzamos con la teoría planteada anteriormente de que el servidor no está guardando los logs a partir de que falla. Por lo tanto hacemos una prueba y es guardar los logs en un servidor remoto.
¿Qué logramos con esto? Bueno, si el problema es que el disco no está escribiendo en esos momentos, entonces los logs no se guardarán y no nos podremos enterar de lo que el kernel nos quiere indicar. Cómo lo resolvemos? Simple, no escribamos los logs a disco, sino que los podemos mandar a una máquina remota.
Atención, la conexión entre la máquina remota y la máquina con problemas debe ser estable y buena, de lo contrario, se perderán los logs. De ser posible que sea una conexión local, aunque en nuestro ejemplo lo hicimos con una máquina a miles de millas de distancia pero ambas con un excelente canal a internet (para eso revisamos la tarjeta de red no?!) Además, sugerimos que al acabar las pruebas que pueden durar algunas horas o días, quitemos el logueo remoto y pongamos nuevamente a guardar los logs localmente.
En la máquina que va a servir de servidor de logs (la máquina buena, la que sencillamente sabemos que el disco funciona) editamos:
vi /etc/sysconfig/syslog
Veamos la primera linea descomentada:
SYSLOGD_OPTIONS="-m 0"
Sencillamente agreguémosle: -r, esto sirve para que la máquina acepte conexiones UDP por el puerto 514 que es el de syslog. Recueden en caso de haber un firewall, abrir este puerto en UDP para la IP de la máquina con problemas.
así quedaría:
SYSLOGD_OPTIONS="-m 0 -r"
Ahora reiniciemos el syslog:
service syslog restart
con esto basta, nuestra máquina amablemente aceptará que logueen en ella remotamente. Ahora indiquemosle a la problemática (el servidor que nos está fallando) que mande los logs para allá. Editemos:
vi /etc/syslog.conf
*.info;mail.none;authpriv.none;cron.none[tab]/var/log/messages
authpriv.* /var/log/secure
mail.* /var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
Muy bien, básicamente estamos diciendo aqui hacia dónde van nuestros logs, todos están yendo a algún lugar dentro de /var/log, esto es, al disco, y no es lo que queremos, queremos evitar escribir a disco pues tenemos la duda de que esté fallando. Cambiémos TODO y pongamos a loguear al servidor remoto (1.2.3.4 le llamaremos, es el que anteriormente configuramos para que aceptara conexiones remotas -r)
kern.* @1.2.3.4
#*.info;mail.none;authpriv.none;cron.none /var/log/messages
*.info;mail.none;authpriv.none;cron.none @1.2.3.4
#authpriv.* /var/log/secure
authpriv.* @1.2.3.4
#mail.* /var/log/maillog
mail.* @1.2.3.4
#cron.* /var/log/cron
cron.* @1.2.3.4
#*.emerg *
*.emerg @1.2.3.4
#uucp,news.crit /var/log/spooler
uucp,news.crit @1.2.3.4
#local7.* /var/log/boot.log
local7.* @1.2.3.4
service syslog restart
y listo, nuestra máquina no va a guardar los logs del syslog en el disco de ella, sino en otra (1.2.3.4 en el ejemplo, insisto porque conozco la mente del ser humano y no dudo que ya pronto me preguntarán por qué no funciona 1.2.3.4).
Miren en la máquina remota (1.2.3.4) y verán que ya comienza a recibir los logs de nuestra máquina problemática. Y ese es el objetivo.
Ahora vigilamos a que falle nuevamente el servidor nuestro y listo, nos pasó, falló, sólo repondía a los ping y a más nada.. así que vamos al servidor remoto y velos los logs (/var/log/messages en nuestro caso) encontrando un error sobre IRQ:
Apr 1 09:11:04 srv3 kernel: hda: lost interrupt
Apr 1 09:11:04 srv3 kernel: hda: lost interrupt
Apr 1 09:11:44 srv3 last message repeated 4 times
Apr 1 09:11:44 srv3 last message repeated 4 times
Apr 1 09:12:54 srv3 last message repeated 7 times
Apr 1 09:12:54 srv3 last message repeated 7 times
Eso sí NO nos gusta. Hay algo raro con las interrupciones. El disco no parece estar físicamente dañado pues no emite errores al syslog de daño, sino algo de interrupciones, colisiones con interrupciones. Normalmente esto se debe a una controladora de disco bien maluca o más fácilmente, que algún otro dispositivo está usando la misma interrupción que el disco.
Veamos las interrupcciones que hay en el sistema y quién las ocupa:
lspci -v
En mi caso sale mucha información, pero sobre todo veo un conflicto entre la controladora de disco y el audio:
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/IC
H4-M) AC'97 Audio Controller (rev 02)
Subsystem: Giga-byte Technology GA-8PE667 Ultra
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at e000 [size=256]
I/O ports at e400 [size=64]
Memory at e8181000 (32-bit, non-prefetchable) [size=512]
Memory at e8182000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
00:1f.1 IDE interface: Intel Corp. 82801DB (ICH4) IDE Controller (rev 02) (prog-
if 8a [Master SecP PriP])
Subsystem: Giga-byte Technology GA-8PE667 Ultra
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at
I/O ports at
I/O ports at
I/O ports at
I/O ports at f000 [size=16]
Memory at 20000000 (32-bit, non-prefetchable) [size=1K]
Ambos usan la misma interrupción, y eso sí que no es agradable. Si hay algo que no debe compartir interrupciones son el DISCO y la tarjeta de RED. Por lo tanto procedamos con las medidas, que deben ser:
1.
Eliminar desde el BIOS o físicamente cuanto dispositivo no estemos usando, estos pueden ser pero no se limitan a: unidad de floppy, puertos USB, tarjeta de sonido, modem, pci para VGA. Estos dispositivos normalmente no se usan cuando damos un servicio de hosting así que al quitarlos hacemos que no hayan conflictos de interrupciones.
2.
Verificar (viendo en /proc/dma) que no hayan situaciones con los DMA, en nuestro caso no las hay.
3.
Desactivar apm y/o acpi y/o apci en el grub. Esto se hace editando /etc/grub.conf y agregando lo siguiente en la linea que comienza con “kernel”
nousb apm=off acpi=off noapic
quedaría algo así (es un ejemplo, tomar la linea correcta del kernel de ustedes):
kernel /vmlinuz-2.4.21-27.0.2.EL ro root=LABEL=/ nousb apm=off acpi=off noapic