Ordre syslog étrange

Avez-vous déjà vu un mauvais ordre dans / var / log / syslog? Je pense que cela ne provoque que 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)

Comme vous pouvez le voir, il y a un mauvais ordre de temps entre les lignes. C'est juste une erreur crontab, ou il y a un problème avec l'horloge système, ou quelque chose?

J'utilise le dernier noyau 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

— Tomasz
source

Est-ce vraiment la mauvaise commande ou juste les horodatages? Dans le premier cas, syslog devrait être responsable, sinon cron ou votre horloge.

— wonce

Il semble que les autres journaux, sauf que cron, sont OK. J'ai ajouté le temps d'enregistrement par script "quelque chose", pas seulement cron et syslog.

— Tomasz

Cela s'est produit sur une de mes boîtes exécutant Fedora, il s'est avéré que rsyslog s'était écrasé, mais journald a conservé les journaux qu'il a transmis à rsyslog une fois qu'il a démarré, ce qui a entraîné le mélange des anciens messages avec les nouveaux. C'était dans fedora 20 cependant.

— Petter H

J'ai rencontré le même problème sur Ubuntu 14.04. Environ 1 message Cron sur 20 a une date d'environ 5 à 7 jours dans le passé. Uniquement avec les messages cron et le problème persiste après un redémarrage.

— Jasper Krijgsman

Je peux confirmer que ce problème, Ubuntu 14.04, se produit avec les messages cron.

— thor

Réponses:

Ceci est délicat, et c'est en fait un bogue dans rsyslog, en particulier RepeatedMsgReduction On, et un changement de comportement avec la version publiée avec Trusty (par rapport aux versions antérieures)

Voir http://bugzilla.adiscon.com/show_bug.cgi?id=527 pour les détails sanglants.

En bref, désactivez RepeatedMsgReduction sur Trusty (c. sudo sed -i -r 's/^\$RepeatedMsgReduction.*/$RepeatedMsgReduction off/' /etc/rsyslog.conf-à-d.). Ce n'est pas utile et ça fait des bêtises.

— Craig Miskell
source

Veuillez ne pas publier la même réponse exacte deux fois. Utilisez plutôt des commentaires pour faire référence à votre première réponse. La meilleure option est de voter pour la clôture en double.

— Sven

L'ironie ... on dirait que vous voudrez peut-être que RepeatedMsgReduction soit activé! : D

— Anonymous Penguin

Qu'est-ce qui vous fait dire ça, Anonymous Penguin?

— Craig Miskell

Il semble que la version 7.4.4-1ubuntu2.7 du package rsyslog corrige ce problème: changelogs.ubuntu.com/changelogs/pool/main/r/rsyslog/…

— Mauro Molinari

Votre machine a peut-être redémarré à ce moment-là? Sur la base de votre journal, il semble que cron ait redémarré au moins. Il est possible que vous ayez une mauvaise batterie CMOS et que votre machine ne garde pas l'heure exacte lorsqu'elle est éteinte.

S'agit-il d'une machine virtuelle? Peut-être qu'il a été migré vers un hôte différent et que l'horloge est devenue incorrecte lors de la migration?

Votre script «quelque chose» définit-il peut-être l'heure par accident?

Vraiment, cela pourrait être un certain nombre de choses. Ce n'est cependant pas un comportement normal.

— devicenull
source

cela ressemble juste à un problème syslog, car j'ai fait une connexion indépendante directement pour exécuter le script et ça a l'air bien, sans espaces ni ordre mélangé.

— Tomasz