Éste me ha desconcertado. Tengo Ubuntu 14.04, hace 3 días (2014-20-10) empezó a ralentizarse.
Lo reproduje abriendo gedit y luego cerrando gedit; cuando el problema está activo, tarda aproximadamente 2 segundos en cerrar un archivo vacío, mientras que sin el problema esto siempre es instantáneo: afecta todo lo demás de manera similar.
top no informa ninguna actividad inusual cuando se produce la congelación, htop lo mismo, iotop también.
El problema solo surge después de 30 minutos de tiempo de actividad, puedo garantizar que a los 29 minutos de tiempo de actividad no pude reproducirlo, a los 31 minutos de tiempo de actividad pude reproducirlo de manera consistente (usando el método anterior, no se iniciaron aplicaciones que no sean terminal y htop) y lo administré. repetir esto 4 o 5 veces (apagando, iniciando y esperando media hora, lo cual fue agradable).
El problema persiste incluso después de reiniciar, pero se puede restablecer apagándolo y encendiéndolo de nuevo. ¿Qué parte de Ubuntu mantiene el estado después de reiniciar pero no de apagar?
Los registros relevantes para este período son syslog, auth.log y Xorg.0.log (examinando el contenido de /var/log durante el tiempo de modificación en el rango especificado)
registro del sistema:
Oct 22 17:21:36 raiden NetworkManager[1102]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Oct 22 17:39:01 raiden CRON[3284]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Oct 22 18:09:01 raiden CRON[3370]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
registro de autorización:
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session closed for user root
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session closed for user root
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session closed for user root
Xorg.0.log: (probablemente acabo de reactivar la computadora)
[ 3466.727] (II) intel(0): switch to mode [email protected] on LVDS1 using pipe 0, position (0, 900), rotation normal, reflection none
[ 3466.880] (II) intel(0): switch to mode [email protected] on VGA1 using pipe 1, position (0, 0), rotation normal, reflection none
Ninguno de ellos indica nada malo y los pasos posteriores para reproducir el problema no indican cambios en los registros, por lo que lo más probable es que se trate de registros inocentes.
Supongo que hay 3 posibles fuentes de este problema:
Instalación de software: instalé algo dudoso
Hice:
- historia | grep apt-get': no se realizaron instalaciones en ese período de tiempo
- Se analizó el historial del administrador de paquetes sinápticos: nada en ese período de tiempo.
- Historial del centro de software: la última actualización fue varias semanas antes (hubo un problema de dependencia, por lo que no había realizado ninguna actualización por un tiempo)
- Instalé Skype para Ubuntu alrededor de ese período de tiempo, pero no hay indicios de que sea causado por Skype (lo eliminé de todos modos)
El trabajo cron va mal
Se verificaron cronjobs en crontab, /etc/cron.d /etc/cron.daily y cada hora, nada que indique que hay algo allí, solo se produce un trabajo cron de PHP cada 30 minutos, pero si fuera cron, lo haría en ciertos puntos durante todo el día, no 30 minutos después del inicio.
El análisis de nuevos procesos que se han iniciado entre el estado sin desaceleración y el estado de desaceleración sugiere que no se inician nuevos procesos (la primera prueba mostró un hilo de kworker, pero es probable que sea solo una coincidencia). Supongo que esto debe significar que es un proceso existente el que lo desencadenó o algo más.
malware
Debido a su carácter esquivo y a la misteriosa ausencia del problema durante 30 minutos (30 minutos parece una cantidad de tiempo elegida por humanos), comencé a pensar que podría ser algún tipo de malware, por improbable que fuera (no había realizado una actualización durante un tiempo y tienen algunos puertos abiertos). Entonces ejecuté rkhunter (buscador de rootkits) pero no se encontró nada extraño.
Otras cosas que he probado:
- Desmarcar ciertos componentes de Compiz: sin cambios
- Reiniciando compiz - sin cambios
- Desmarcar todos los componentes de compiz: sin cambios (excepto por mi lucha para que la computadora vuelva a ser utilizable)
- Tocar varios instrumentos musicales mientras se espera que el tiempo de actividad llegue a 30 minutos y luego observar los resultados de top y htop para detectar cualquier cambio sospechoso, nada extraño.
¿A alguien le ha sucedido algo similar a esto o podría indicarme la dirección correcta? Si lo hace, presionaré el botón de votar repetidamente en su respuesta (me aseguraré de que sea un número impar).
Respuesta1
Hay algunas formas de configurar cron para ejecutar un trabajo 30 minutos después del inicio. Jenkins lo hace aplicando hash a la función y usando, H/30 * * * *por ejemplo. También podría ser un hilo que duerme durante 30 minutos y genera un proceso silencioso que mata la CPU.
Algunas ideas allí:
¿Probaste htop como root? Algunos procesos pueden ser invisibles, esto lo he visto especialmente en Debian.
¿Intentaste cerrar sesión o volver a iniciarla cuando ocurrió el problema? Podría ser el administrador de ventanas o un problema de sesión.
Si cerrar sesión/iniciar sesión no funciona, puede intentar reiniciar su administrador de sesión. Creo que es lightdm por defecto, así que sudo service lightdm restartdebería hacerlo.
Respuesta2
Esto fue causado pordatos INTELIGENTEShabilitado para la unidad en cuestión.
Deshabilitar los datos SMART resolvió esto:
sudo smartctl --smart=off /dev/sda
Presumiblemente siguió ejecutando algún tipo de autoprueba interna 30 minutos después de que el disco giró y entró en un bucle; Como esto estaba en la capa de hardware, el resto de la computadora no estaba al tanto de lo que estaba sucediendo, por lo que no pude ver ningún proceso en particular responsable del bloqueo de E/S ni ningún proceso que acaparara los recursos.