[explorer]

Esto empieza a ser molesto... Desde abril se nos ha caído en los siguientes momentos:

Fecha Tipo
15/8/15 00:17 reboot (he visto con mis propios ojos en el log de actividad que los procesos se morían e iniciado el reboot de forma manual para cazar el posible culpable)
15/8/15 0:01 Server check
14/8/15 23:54 Remote reboot
14/8/15 2:10 Remote reboot
14/8/15 0:33 Remote reboot
20/7/15 21:20 HARD Reboot
21/5/15 15:40 Remote reboot
6/4/15 9:44 Remote reboot
27/2/15 14:01 Remote reboot
27/2/15 7:57 Remote reboot
29/1/15 0:17 Remote reboot
8/12/14 2:13 Remote reboot
4/1/14 14:26 OS Reinstall


Señores de OVH: sospechamos de un fallo de hardware. No es de disco, porque ya sabemos qué aspecto tienen esos fallos. Sospechamos que puede ser de memoria o de CPU.

Tenemos alquilado el servidor hasta fin de año. ¿Alguna sugerencia? ¿Podríamos pedir un servidor de similares características a cambio de este? Nosotros nos encargaríamos del paso de los servicios e información.

Por favor, ¡ayuda!

Esto es lo que podemos mostrar:

Aug 15 00:15:32 ns3369693 kernel: irq 16: nobody cared (try booting with the "irqpoll" option)
Aug 15 00:15:32 ns3369693 kernel: CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.10.23-xxxx-grs-ipv6-64 #1
Aug 15 00:15:32 ns3369693 kernel: Hardware name: System manufacturer System Product Name/P8H77-M PRO, BIOS 1401 08/20/2013
Aug 15 00:15:32 ns3369693 kernel: ffff8807f386628c ffff88081fbc3e38 ffffffff81dde9c6 ffff88081fbc3e68
Aug 15 00:15:32 ns3369693 kernel: ffffffff81121c88 0000000100025d99 ffff8807f3866200 0000000000000010
Aug 15 00:15:32 ns3369693 kernel: 0000000000000000 ffff88081fbc3eb8 ffffffff8112219e ffff88081fbc3eb8
Aug 15 00:15:32 ns3369693 kernel: Call Trace:
Aug 15 00:15:32 ns3369693 kernel:   [] dump_stack+0x19/0x1b
Aug 15 00:15:32 ns3369693 kernel: [] __report_bad_irq+0x38/0xd0
Aug 15 00:15:32 ns3369693 kernel: [] note_interrupt+0x20e/0x250
Aug 15 00:15:32 ns3369693 kernel: [] handle_irq_event_percpu+0x89/0x160
Aug 15 00:15:32 ns3369693 kernel: [] handle_irq_event+0x3c/0x60
Aug 15 00:15:32 ns3369693 kernel: [] handle_fasteoi_irq+0x54/0xf0
Aug 15 00:15:32 ns3369693 kernel: [] handle_irq+0x1d/0x30
Aug 15 00:15:32 ns3369693 kernel: [] do_IRQ+0x55/0xd0
Aug 15 00:15:32 ns3369693 kernel: [] common_interrupt+0x67/0x67
Aug 15 00:15:32 ns3369693 kernel:   [] ? cpuidle_enter_state+0x59/0x160
Aug 15 00:15:32 ns3369693 kernel: [] ? cpuidle_enter_state+0x52/0x160
Aug 15 00:15:32 ns3369693 kernel: [] cpuidle_idle_call+0x9b/0x140
Aug 15 00:15:32 ns3369693 kernel: [] ? __atomic_notifier_call_chain+0xd/0x10
Aug 15 00:15:32 ns3369693 kernel: [] arch_cpu_idle+0x9/0x20
Aug 15 00:15:32 ns3369693 kernel: [] cpu_startup_entry+0xc7/0x190
Aug 15 00:15:32 ns3369693 kernel: [] start_secondary+0x1e0/0x1e7
Aug 15 00:15:32 ns3369693 kernel: handlers:
Aug 15 00:15:32 ns3369693 kernel: [] mpt_interrupt
Aug 15 00:15:32 ns3369693 kernel: Disabling IRQ #16

[explorer]

Nueva caída, hoy a las 07:14. Se sigue cumpliendo la regla de un cuelgue cada mes, aprox.

[explorer]

Encontré la causa y la solución: hay que cambiar el kernel "grs" por un "std".

http://www.webmaster-hub.com/topic/5...r-sur-kimsufi/

Ahora la pregunta es: ¿OVH puede encargarse de este cambio de kernel?

[alvaroag]

Todos los servidores de la gama OVH de 2014 en adelante incluyen KVM/IP, lo puedes acceder desde el manager. Lo digo con la intención de que puedan ver la pantalla al momento en que el servidor deja de responder, ya que eso puede ser mas revelador que los logs. Por ejemplo, podrías ver todos los detalles de un kernel panic.

[explorer]

No lo sabemos. Justo unos segundos antes de que llegaran los avisos automáticos de parte del sistema de monitorización de OVH, con el mensaje de que se iba a encargar el servicio técnico de OVH, yo ya estaba reiniciando la máquina a través del panel de control, ya que era mediodía y no podía hacer esperar a 600 personas (acceder a su correo electrónico).

Este sería el primer fallo hardware desde que se contrató el servidor, hace 18 meses. Esperemos que no pase hasta junio, donde emigraremos a otra, ya que tenemos que librarnos del problema software.

Sí que podríamos contratar el KVM para probar a actualizar manualmente el núcleo Linux, pero... ya he tenido malas experiencias y no me quiero arriesgar a dejar el sistema bloqueado.

De momento, ya hemos hecho copia de seguridad y estamos más tranquilos. Si el fallo se sigue reproduciendo cada 30 días, podemos aguantar un poco más.

[alvaroag]

Tienes opción de KVM/IP?

[mgsalinero]

¿Es posible un fallo en la alimentación? Que os comentan de OVH.

[explorer]

Otra vez... que se nos ha colgado a las 13:57... dos veces en el mismo día.

Pero esta vez no es por el sistema operativo, sino del hardware. Ni siquiera ha quedado registrado en el kernel.log.

Vamos de mal en peor.

[explorer]

Confirmado: se nos cuelga una vez cada 30 días, más o menos.

Esta máquina ya no es fiable.

[mgsalinero]

Curioso que tenga esta limitación y haga un stack overflow. Sin embargo yo esperaría a ver si vuelve a suceder o si sucede a menudo. Si tarda 330 días en producirse aún tenéis tiempo para decidir que hacer. Igualmente, otra opción que tenéis, si ocurre regularmente cada 330 días, es que reiniciéis el servidor antes de que esto ocurra y que lo hagais cuando el servidor apenas tenga uso.

Aunque si, recomendaría preparar una copia de seguridad prepararos para reinstalar todo rápidamente y dejarlo operativo en unas horas y proceder a la actualización del kernel y si falla el sistema, reinstalar.

Un saludo

[explorer]

Buenas...

Tenemos un dedicado con un Debian

Linux 3.10.23-xxxx-grs-ipv6-64 #1 SMP Mon Dec 9 19:06:18 CET 2013 x86_64 GNU/Linux

Esta madrugada, a las 01:50 ha salido este error y ha dejado buena parte de los sistemas inoperativos, por lo que hemos tenido que reiniciar, después de más de 330 días sin hacerlo:

PAX: size overflow detected in function atomic_add_return /var/home/fx/src/ovh-kernel/ovhkernel-xxxx-grs-ipv6-32/linux-3.10.23/arch/x86/include/asm/atomic.h:337 cicus.114_12 max, count: 3

En otro foro se indica que está solucionado con la v3.12 del kernel.

Ahora mismo, podríamos intentar cambiar a un kernel v3.15 o v3.16, pero claro, nos arriesgamos a que todo el sistema quede inoperativo.

También es posible que el error no vuelva a aparecer hasta dentro de un año...

Otra opción es contratar una máquina nueva, con un nuevo kernel.

¿A alguien más le ha pasado esto?