Dziwne zamówienie syslog

Czy kiedykolwiek widziałeś niewłaściwą kolejność w / var / log / syslog? Myślę, że powoduje to tylko 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)

Jak widać, między wierszami występuje zły porządek czasu. To tylko błąd crontab, czy jest jakiś problem z zegarem systemowym, czy coś?

Korzystam z najnowszego jądra 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
źródło

Czy tak naprawdę kolejność jest nieprawidłowa, czy tylko znaczniki czasu? W pierwszym przypadku syslog powinien być odpowiedzialny, w przeciwnym razie cron lub zegar.

— wygrał

Wygląda na to, że inne dzienniki oprócz crona są w porządku. Dodałem czas logowania przez skrypt „coś”, a nie tylko cron i syslog.

— Tomasz

Stało się to na pudełku mojej działającej fedory, okazało się, że rsyslog się zawiesił, ale dziennik prowadził dzienniki, które przesłał do rsyslogu po uruchomieniu, w wyniku czego stare wiadomości zostały pomieszane z nowymi. To było w Fedorze 20.

— Petter H

Ten sam problem napotkałem na Ubuntu 14.04. Około 1 na każde 20 wiadomości cron ma datę około 5-7 dni w przeszłości. Tylko w przypadku wiadomości CRON problem występuje po ponownym uruchomieniu.

— Jasper Krijgsman,

Mogę potwierdzić ten problem, Ubuntu 14.04, dzieje się z komunikatami cron.

— thor

Odpowiedzi:

Jest to podstępne i w rzeczywistości jest to błąd w rsyslog, szczególnie RepeatedMsgReduction On, oraz zmiana zachowania w wersji wydanej z Trusty (w porównaniu do wcześniejszych wersji)

Zobacz szczegóły dotyczące http://bugzilla.adiscon.com/show_bug.cgi?id=527 .

Krótko mówiąc, wyłącz RepeatedMsgReduction na Trusty (tj sudo sed -i -r 's/^\$RepeatedMsgReduction.*/$RepeatedMsgReduction off/' /etc/rsyslog.conf .). To nie jest pomocne i robi głupie rzeczy.

— Craig Miskell
źródło

Nie publikuj dokładnie tej samej odpowiedzi dwa razy. Zamiast tego użyj komentarzy, aby odnieść się do pierwszej odpowiedzi. Najlepszym rozwiązaniem jest głosowanie na zamknięcie jako duplikat.

— Sven

Ironia ... wygląda na to, że możesz chcieć włączyć RepeatedMsgReduction! : D

— Anonimowy pingwin

Co sprawia, że tak mówisz, Anonimowy Pingwin?

— Craig Miskell,

Wydaje się, że wersja 7.4.4-1ubuntu2.7 pakietu rsyslog rozwiązuje ten problem: changelogs.ubuntu.com/changelogs/pool/main/r/rsyslog/…

— Mauro Molinari

Czy Twoja maszyna mogła się wtedy ponownie uruchomić? Na podstawie twojego dziennika wydaje się, że przynajmniej cron został zrestartowany. Możliwe, że masz złą baterię CMOS, a urządzenie nie dotrzymuje dokładnego czasu po wyłączeniu.

Czy to jest maszyna wirtualna? Być może został migrowany do innego hosta, a zegar stał się niepoprawny podczas migracji?

Czy twój skrypt „czegoś” może przypadkowo ustawić czas?

Naprawdę może to być dowolna liczba rzeczy. Nie jest to jednak normalne zachowanie.

— devicenull
źródło

wygląda to tylko na problem z syslogiem, ponieważ dokonałem niezależnego logowania bezpośrednio do uruchomienia skryptu i wygląda dobrze, bez spacji i mieszanej kolejności.

— Tomasz