Orden de syslog extraño

¿Alguna vez has visto un orden incorrecto en / var / log / syslog? Creo que solo causa crontab.

Jun 28 22:20:01 alex CRON[2327]: (root) CMD (something > /dev/null)
Jun 28 22:21:01 alex CRON[2700]: (root) CMD (something > /dev/null)
Jun 21 03:49:01 alex CRON[2753]: (root) CMD (something > /dev/null)
Jun 28 22:23:01 alex CRON[2754]: (root) CMD (something > /dev/null)
Jun 27 05:08:01 alex CRON[2813]: (root) CMD (something > /dev/null)
Jun 26 00:19:01 alex CRON[2816]: (root) CMD (something > /dev/null)
Jun 28 22:25:01 alex CRON[2816]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi)
Jun 28 22:25:01 alex CRON[2821]: (root) CMD (something > /dev/null)
Jun 28 22:27:01 alex CRON[3225]: (root) CMD (something > /dev/null)
Jun 28 22:28:01 alex CRON[3240]: (root) CMD (something > /dev/null)
Jun 28 22:30:01 alex CRON[3290]: (root) CMD (something > /dev/null)
Jun 26 12:03:01 alex CRON[3291]: message repeated 2 times: [ (root) CMD (something > /dev/null)]
Jun 28 22:30:01 alex CRON[3291]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi)
Jun 28 22:31:01 alex CRON[3659]: (root) CMD (something > /dev/null)
Jun 28 22:32:01 alex CRON[3754]: (root) CMD (something > /dev/null)
Jun 16 06:41:01 alex CRON[3846]: (root) CMD (something > /dev/null)
Jun 28 22:35:58 alex cron[909]: (CRON) INFO (pidfile fd = 3)
Jun 28 22:35:58 alex cron[944]: (CRON) STARTUP (fork ok)
Jun 28 22:35:58 alex cron[944]: (CRON) INFO (Running @reboot jobs)
Jun 28 22:36:01 alex CRON[1428]: (root) CMD (something > /dev/null)
Jun 28 22:37:01 alex CRON[3050]: (root) CMD (something > /dev/null)
Jun 28 22:38:01 alex CRON[3082]: (root) CMD (something > /dev/null)
Jun 28 22:39:01 alex CRON[3114]: (root) CMD (something > /dev/null)

Como puede ver, hay un mal orden de tiempo entre líneas. ¿Es solo un error crontab, o hay algún problema con el reloj del sistema, o algo así?

Estoy ejecutando el último kernel Ubuntu 14.04:

Linux alex 3.13.0-30-generic #54-Ubuntu SMP Mon Jun 9 22:45:01 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

— Tomász
fuente

¿Es realmente el orden incorrecto o solo las marcas de tiempo? En el primer caso, syslog debe ser responsable, de lo contrario cron o su reloj.

— ganó el

Parece que los otros registros, excepto cron, están bien. Agregué tiempo de registro mediante el script "algo", no solo cron y syslog.

— Tomasz

Esto sucedió en una caja mía con fedora, resultó que rsyslog se había bloqueado, pero journald mantuvo registros que reenvió a rsyslog una vez que comenzó, lo que resultó en que los mensajes antiguos se mezclaron con los nuevos. Sin embargo, esto fue en Fedora 20.

— Petter H

He encontrado el mismo problema en Ubuntu 14.04. Aproximadamente 1 de cada 20 mensajes cron tiene una fecha de aproximadamente 5-7 días en el pasado. Solo con mensajes cron y el problema persiste después de un reinicio.

— Jasper Krijgsman

Puedo confirmar que este problema, Ubuntu 14.04, ocurre con mensajes cron.

— thor

Respuestas:

Este es un truco, y en realidad es un error en rsyslog, específicamente RepeatedMsgReduction On, y un cambio de comportamiento con la versión lanzada con Trusty (en comparación con versiones anteriores)

Ver http://bugzilla.adiscon.com/show_bug.cgi?id=527 para los detalles sangrientos.

En resumen, apague RepeatedMsgReduction en Trusty (es decir sudo sed -i -r 's/^\$RepeatedMsgReduction.*/$RepeatedMsgReduction off/' /etc/rsyslog.conf). No es útil y hace cosas tontas.

— Craig Miskell
fuente

No publique exactamente la misma respuesta dos veces. Utilice los comentarios para referirse a su primera respuesta. La mejor opción es votar por cierre como duplicado.

— Sven

La ironía ... ¡parece que querrías que RepeatedMsgReduction esté activado! : D

— Anonymous Penguin

¿Qué te hace decir eso, Anonymous Penguin?

— Craig Miskell

Parece que la versión 7.4.4-1ubuntu2.7 del paquete rsyslog soluciona este problema: changelogs.ubuntu.com/changelogs/pool/main/r/rsyslog/…

— Mauro Molinari

¿Quizás su máquina se reinició entonces? Según su registro, parece que cron se reinició al menos. Es posible que tenga una batería CMOS defectuosa y que su máquina no mantenga la hora exacta cuando está apagada.

¿Es esta una máquina virtual? ¿Quizás se migró a un host diferente y el reloj se volvió incorrecto durante la migración?

¿Su guión de 'algo' tal vez establece la hora por accidente?

Realmente, esto podría ser cualquier cantidad de cosas. Sin embargo, este no es un comportamiento normal.

— devicenull
fuente

parece solo un problema de syslog, porque hice un inicio de sesión independiente para ejecutar el script y se ve bien, sin espacios ni orden mixto.

— Tomasz