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

ubuntu cron syslog time 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