Mi servidor Redhat falla cada tres semanas aproximadamente a las 4:15 am los domingos por la mañana. (bueno, eran domingos, los dos últimos fueron jueves por la mañana a las 4:15). Al observar los registros (mysql, httpd, mensajes), no hay pistas de por qué. Simplemente parecen detenerse.
Ejecuté un pequeño script para tomar lecturas de memoria cada 15 minutos y también se detiene (con lecturas normales) en ese momento.
El servidor es remoto en un proveedor, por lo que solo puedo acceder a él a través de la web. Yo uso Plesk.
Parece ser un trabajo configurado o algo que está causando el problema. No puedo ver nada en crontab.
Entonces mi pregunta es... ¿a alguien más le ha pasado esto y puede ofrecerme algún consejo? Fallando en eso.
¿Alguien conoce alguna forma de obtener un registro más detallado que el que ofrece el archivo de mensajes? Estaba pensando en un programa de grabación estilo caja negra o tal vez algo tan simple como una opción en algún lugar para aumentar el nivel de informes en el registro de mensajes.
Gracias
Respuesta1
Estos son los momentos en que se programan los trabajos de cron.daily, por lo que buscaría en /etc/cron.daily o semanalmente o mensualmente como los primeros sospechosos.
Puede instalarlo encima y grabará una instantánea de los procesos cada 10 minutos.
Alternativamente, puedes instalar psacct y usar accton y lastcomm para ver qué se estaba ejecutando.
activar la auditoría también es una opción, ver auditd(8)
Respuesta2
Puede habilitar los volcados de memoria, que copiarán la memoria del sistema en un archivo cuando un servidor falle.
El siguiente problema es qué hacer con el archivo coredump... Si tiene a alguien cerca que sepa todo sobre gdb, es posible que pueda hacer algo al respecto... o puede usar el comando "strings" para volcar todo. del texto del archivo coredump, y tal vez puedas encontrar algo.
Respuesta3
inicie sesión en un cuadro diferente que esté bien conectado, ejecute screen, ssh en el servidor y siga kern.log, daemon.log, syslog, mensajes en ventanas de pantalla individuales. (control-A, c para crear una nueva ventana, Control-A,D para separar, pantalla -r para reanudar)
Cuando el servidor se bloquea nuevamente, debería tener el final de los registros en su sesión de pantalla, incluso si no se han vaciado correctamente en el disco cuando la máquina se bloquea.
Si sospecha que hay pánico en el kernel o ¡ups!
kernel.panic=5 kernel.panic_on_oops=5
en su sysctl.conf o archivo equivalente esperará 5 segundos, posiblemente permitiendo que las unidades se vacíen, y luego se reiniciará.