Depuración de bloqueo: systemd pierde mis registros

Desde que me "actualicé" a systemd en Arch Linux, sigo perdiendo registros cuando ocurre un bloqueo inesperado. Llegué al mismo problema de pérdida de registro hace un mes y simplemente volví a encontrarlo. También hay otras confirmaciones independientes .

Situación:

• Mientras hacía algunas cosas en Java y con utilidades relacionadas con la red, vi que KDE (el reloj) estaba congelado. El ventilador de la CPU se volvió ruidoso y el calor aumentaba. Sin embargo, el puntero del mouse aún se podía mover.
• Traté de ssh desde otra máquina (falló debido a "no hay ruta al host")
• Esperé unos minutos, tal vez el perro guardián de NMI podría matar la tarea ofensiva. No dados.
• Ctrl+ Alt+ F1tampoco funcionó, incluso después de SysRq+R
• Como los pasos anteriores no funcionaron, decidí emitir la secuencia REI de SysRq. Después E, la pantalla se volvió negra, pero tampoco consola. Ni siquiera después de SysRq+K
• Por lo tanto, esta sesión parece estar perdida, lo único que se puede hacer es recopilar información de depuración. Mirando Wikipedia , decidí presionar SysRq+ d(mostrar bloqueos retenidos) entre otros.
• Después de presionar SysRq+ S, esperé un segundo y luego reinicié con SysRq+ B.
• Después de reiniciar e iniciar sesión en una consola, no vi rastros de ningún bloqueo. La entrada registrada más recientemente fue el uso de Wireshark, pero todavía había un espacio de 45 minutos.

(Estaba ejecutando Linux v3.8-rc5-218-ga56e160 por cierto)

Entonces, ¿cómo puedo asegurarme de que mis registros se retienen cuando se reinicia anormalmente debido a un bloqueo?

Entonces pregunté por el canal #systemd IRC y resultó que journald (el demonio de registro de systemd) no vacía periódicamente los registros en el disco. Esto significa que sus registros siempre están en riesgo en cualquier momento.

El envío SIGUSR2a los journaldregistros de causas se escribirá en el disco, pero si lo hace varias veces, se crearán muchos archivos. (la opción se describe realmente como "registro giratorio").

Al final, decidí ir con otra sugerencia: usar un demonio syslog dedicado para recopilar registros del kernel. Como se sugirió rsyslog (y ya tenía experiencia con él), exploré más esa opción. He escrito algunos detalles más en Arch Wiki sobre el uso de rsyslog.

La idea es ejecutar rsyslog, recolectando solo datos del núcleo. Como rsyslog lee /proc/kmsg(que solo permite un solo lector) y journald lee /dev/kmsg(múltiples lectores permitidos), no hay forma de que los demonios pierdan registros (¡muy importante para mí!). Configure rsyslog para escribir mensajes del núcleo en un archivo y asegúrese de que este archivo gire para evitar consumir su espacio en el disco.

Esta solución no es perfecta:

• Se pierden otros registros (por ejemplo, de NetworkManager). Esto podría resolverse reenviando más registros de syslog a journald (¡esto significa duplicación!)
• Duplicación de registros. Los mensajes del kernel se escriben en dos archivos. Esto no es un problema, en general el número de registros es pequeño y prefiere tener más copias de los registros que ninguno. También puede usar herramientas rápidas como grepen el archivo de registro único o más lento, pero más sofisticado journalctl.

Hay un elemento TODO para enjuagar los registros con mayor frecuencia, pero aún no es lo suficientemente confiable:

diario: envíe mensajes de marcadores de vez en cuando e inmediatamente sincronícelos con fdatasync () para tener sincronizaciones garantizadas por hora.

Ahora, con suerte, systemd / journald tendrá la opción de escribir los registros en el disco, pero mientras tanto podemos combinar herramientas para lograr el objetivo.

Hay dos actualizaciones:

1. Ahora, con suerte, systemd / journald tendrá la opción de escribir los registros en el disco, pero mientras tanto podemos combinar herramientas para lograr el objetivo.

Hay una opción --sync:

Pide al daemon de diario que escriba todos los datos de diario aún no escritos en el sistema de archivos de respaldo y sincronice todos los diarios. Esta llamada no regresa hasta que se complete la operación de sincronización. Este comando garantiza que los mensajes de registro escritos antes de su invocación se almacenen de forma segura en el disco en el momento en que regresa.

--syncdisponible desde v228:

journalctl obtuvo un nuevo modificador "--sync" que le pide al demonio del diario que escriba todos los mensajes de registro no escritos hasta ahora en el disco y sincronice los archivos, antes de regresar.

2. Resulta que journald (el demonio de registro de systemd) no vacía periódicamente los registros en el disco. Esto significa que sus registros siempre están en riesgo en cualquier momento.

man journald.conf(5) dice:

SyncIntervalSec =

El tiempo de espera antes de sincronizar los archivos de diario al disco. Después de la sincronización, los archivos de diario se colocan en el estado DESCONECTADO. Tenga en cuenta que la sincronización se realiza incondicionalmente inmediatamente después de que se haya registrado un mensaje de registro de prioridad CRIT, ALERT o EMERG. Por lo tanto, esta configuración solo se aplica a los mensajes de los niveles ERR, WARNING, NOTICE, INFO, DEBUG. El tiempo de espera predeterminado es de 5 minutos.

SyncIntervalSec=disponible desde v199:

journald ahora vaciará explícitamente los archivos del diario al disco a más tardar 5 minutos después de cada escritura. El archivo también se marcará como desconectado hasta la próxima escritura. Esto debería aumentar la confiabilidad en caso de un choque. El retraso de sincronización se puede configurar a través de SyncIntervalSec = en journald.conf.

Ver también:

journald: despacho SIGTERM / SIGINT con baja prioridad

Asegurémonos de procesar todos los datos de registro en cola antes de salir, para que no perdamos innecesariamente mensajes al cerrar.