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?
systemd
logs
debugging
systemd-journald
Lekensteyn
fuente
fuente
systemd
o no? Recientemente estoy viendo problemas similares. He publicado los detalles aquí -> unix.stackexchange.com/questions/414871/…SyncIntervalSec
opción (entre otras) en manjournald.conf(5)
.man jounrnald.conf(5)
: SyncIntervalSec = ... 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. ¿No significa esto simplemente que si se registra un error crítico se supone que debe sincronizarse "inmediatamente" sin esperar el intervalo? Lo que significa que si ocurre un error crítico se supone que lo veremos en losjournald
registros. ¡¿Me estoy perdiendo de algo?!Respuestas:
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
SIGUSR2
a losjournald
registros 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:
grep
en el archivo de registro único o más lento, pero más sofisticadojournalctl
.Hay un elemento TODO para enjuagar los registros con mayor frecuencia, pero aún no es lo suficientemente confiable:
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.
fuente
Hay dos actualizaciones:
Hay una opción
--sync
:--sync
disponible desdev228
:man journald.conf(5)
dice:SyncIntervalSec=
disponible desdev199
:Ver también:
journald: despacho SIGTERM / SIGINT con baja prioridad
fuente