/var/log/messages
, /var/log/syslog
i niektóre inne pliki dziennika używają znacznika czasu zawierającego czas bezwzględny, np Jan 13 14:13:10
.
/var/log/Xorg.0.log
oraz /var/log/dmesg
, podobnie jak wynik $ dmesg
, użyj formatu, który wygląda
[50595.991610] malkovich: malkovich malkovich malkovich malkovich
Zgaduję / zbieram, że liczby reprezentują sekundy i mikrosekundy od uruchomienia.
Jednak moja próba skorelowania tych dwóch zestawów znaczników czasu (przy użyciu danych wyjściowych z uptime
) dała rozbieżność około 5000 sekund.
To mniej więcej tyle czasu, ile czasu mój komputer został zawieszony.
Czy istnieje wygodny sposób odwzorowania numerycznych znaczników czasu używanych przez dmesg i Xorg na absolutne znaczniki czasu?
aktualizacja
Jako wstępny krok w kierunku wyjaśnienia tego, a także, aby mam nadzieję, że moje pytanie będzie nieco jaśniejsze, napisałem skrypt w języku Python, który analizuje /var/log/syslog
i wyświetla odchylenie czasu. Na moim komputerze z systemem Ubuntu 10.10 plik ten zawiera wiele linii pochodzących z jądra, które są stemplowane zarówno znacznikiem czasu dmesg, jak i znacznikiem czasu syslog. Skrypt wyświetla wiersz dla każdego wiersza w tym pliku, który zawiera znacznik czasu jądra.
Stosowanie:
python syslogdriver.py /var/log/syslog | column -nts $'\t'
Wyjściowe dane wyjściowe (definicje kolumn poniżej):
abs abs_since_boot rel_time rel_offset message
Jan 13 07:49:15 32842.1276569 32842.301498 0 malkovich malkovich
... rel_offset
wynosi 0 dla wszystkich linii pośrednich ...
Jan 13 09:55:14 40401.1276569 40401.306386 0 PM: Syncing filesystems ... done.
Jan 13 09:55:14 40401.1276569 40401.347469 0 PM: Preparing system for mem sleep
Jan 13 11:23:21 45688.1276569 40402.128198 -5280 Skipping EDID probe due to cached edid
Jan 13 11:23:21 45688.1276569 40402.729152 -5280 Freezing user space processes ... (elapsed 0.03 seconds) done.
Jan 13 11:23:21 45688.1276569 40402.760110 -5280 Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Jan 13 11:23:21 45688.1276569 40402.776102 -5280 PM: Entering mem sleep
... rel_offset
wynosi -5280 dla wszystkich pozostałych linii ...
Jan 13 11:23:21 45688.1276569 40403.149074 -5280 ACPI: Preparing to enter system sleep state S3
Jan 13 11:23:21 45688.1276569 40403.149477 -5280 PM: Saving platform NVS memory
Jan 13 11:23:21 45688.1276569 40403.149495 -5280 Disabling non-boot CPUs ...
Jan 13 11:23:21 45688.1276569 40403.149495 -5280 Back to C!
Jan 13 11:23:21 45688.1276569 40403.149495 -5280 PM: Restoring platform NVS memory
Jan 13 11:23:21 45688.1276569 40403.151034 -5280 ACPI: Waking up from system sleep state S3
... Ostatnie linie znajdują się nieco dalej, wciąż znacznie powyżej końca wyjścia. Niektóre z nich prawdopodobnie zostały zapisane w dmesg
okrągłym buforze przed zawieszeniem i zostały przeniesione dopiero syslog
później. To wyjaśnia, dlaczego wszystkie mają ten sam znacznik czasu syslog.
Definicje kolumn:
abs
to czas rejestrowany przez syslog.
abs_since_boot
to ten sam czas w sekundach od uruchomienia systemu, na podstawie zawartości /proc/uptime
i wartości time.time()
.
rel_time
jest znacznikiem czasu jądra.
rel_offset
jest różnica między abs_since_boot
i rel_time
. Zaokrąglam to do kilkudziesięciu sekund, aby uniknąć jednorazowych błędów z powodu bezwzględnych (tj. syslog
Generowanych) znaczników czasowych posiadających jedynie precyzję sekundową. W rzeczywistości nie jest to właściwy sposób, aby to zrobić, ponieważ naprawdę (tak myślę ...) po prostu zmniejsza szansę na wystąpienie błędu przekroczenia 10. Jeśli ktoś ma lepszy pomysł, daj mi znać.
Mam również pytania dotyczące formatu daty syslog; w szczególności zastanawiam się, czy kiedykolwiek pojawi się w tym roku. Zgaduję, że nie, a w każdym razie najprawdopodobniej mógłbym pomóc sobie w uzyskaniu tych informacji w TFM, ale jeśli ktoś się dowie, będzie to przydatne. .. Zakładając oczywiście, że ktoś użyje tego skryptu w pewnym momencie w przyszłości, zamiast po prostu wykasować kilka wierszy kodu Perla.
Kolejny:
Więc jeśli jakieś powitanie nie zostanie mi przekazane przez jednego z was, moim następnym krokiem będzie dodanie funkcji, aby uzyskać przesunięcie czasu dla określonego znacznika czasu jądra. Powinienem być w stanie nakarmić skrypt jednym zestawem syslogów wraz ze znacznikiem czasu jądra, aby uzyskać absolutny znacznik czasu. Następnie mogę wrócić do debugowania moich problemów Xorg, które w tej chwili mi uciekają.
źródło
sort
, mieć rok, strefę czasową itp. +1 dla skryptu python.Freezing user space processes
co wyraźnie zostało wykonane przed snem.[12345.6789]..
) emitowanego przez jądro, więc działa poprawnie , z zastrzeżeniem kwestii poruszonych przez mój ostatni komentarz. Nie jestem pewien, co naprawdę powinno tutaj robić jądro; zależy to od tego, co te znaczniki czasu związane ze startem mają oznaczać. Czas działania (w przeciwieństwie do czasu od rozruchu) może mieć znaczenie w niektórych kontekstach. Myślę, że idealnie byłby wiarygodny zapis obu tych wartości.Odpowiedzi:
Ciekawy problem, nie jestem pewien, czy kiedykolwiek próbowałem to zrobić. Ale zauważyłem znacznik czasu, o którym mówisz, i zawsze uważałem, że minęły sekundy od uruchomienia.
W moim dzienniku systemowym, który mam na serwerze, mam:
Wyobrażam sobie, że jest to dość spójne wśród większości dystrybucji Linuksa, ponieważ to jądro wyrzuca to z siebie.
I tutaj mam datę wraz ze znacznikiem czasu.
źródło
Możesz spróbować:
Najpierw uzyskaj znacznik czasu pliku dmesg (zakładam, że będzie to czas 0 dmesg). Użyjesz
Możesz przekonwertować sekundy na datę czytelną dla człowieka za pomocą
Aby zobaczyć czytelny czas zdarzenia, dodaj w sekundach od zdarzenia w dmesg. Jeśli zdarzenie dmesg miało 55.290387 sekund, dodaj 55 lub 55.290387:
Innym sposobem na przekształcenie zakorzenionych w epoce sekund w czas czytelny jest użycie date -d zgodnie z sugestią. Jeśli powiesz „data”, aby reprezentowała czas dostarczony z opcją -d, możesz wskazać, że czas do konwersji jest wyrażony w sekundach od epoki za pomocą @.
To daje ci coś takiego jak „czw 13 stycznia 15:26:18 CST 2011” jako wynik.
wydrukuje bieżący czas w formacie sekund od epoki.Nie pamiętam, jak wykonywać matematykę powłoki, więc zwykle używam metody perl jak wyżej. :)
źródło
date -d @$((1294953978 + 55))
, przynajmniej pod bash. Jednak niektóre znaczniki czasu jądra są wypaczone, co oznacza, że czasy wytworzone tą metodą byłyby wcześniejsze niż odpowiadające im znaczniki czasu w/var/log/syslog
. Wygląda na to, że dzieje się tak w wyniku zdarzeń zawieszenia do pamięci RAM, prawdopodobnie oprócz hibernacji i prawdopodobnie innych rzeczy, ponieważ czas jądra nie zwiększa się w tych okresach. Zobacz aktualizację pytania, aby uzyskać więcej informacji.Najłatwiejszym sposobem zmapowania numeru z dmesg na datę jest użycie
date
programu.To polecenie wyświetla datę bieżącego czasu minus 50595 sekund.
Od
man date
:Liczba równa się czasowi włączenia, a nie czasowi, który upłynął od czasu rozruchu.
źródło
Ponieważ zauważyłeś zmianę skosu czasu podczas zawieszania / wznawiania, zauważę, że jest to udokumentowane w co najmniej jednym miejscu. Strona podręcznika dmesg (1) mówi:
Nie mogłem znaleźć sposobu, aby jądro utrzymywało te znaczniki czasu w synchronizacji z czasem ściany.
źródło
Szybko, brudno, działa.
Zawartość tego skryptu:
Przykładowe dane wyjściowe są następujące:
źródło