Порівнювальні / var / log / * часові позначки

/var/log/messages, /var/log/syslogта деякі інші файли журналів використовують часову позначку, яка містить абсолютний час, наприклад Jan 13 14:13:10.

/var/log/Xorg.0.logі /var/log/dmesg, як і вихід $ dmesg, використовувати формат, який виглядає так

[50595.991610] malkovich: malkovich malkovich malkovich malkovich

Я здогадуюсь / збираю, що цифри представляють секунди та мікросекунди з моменту запуску.

Однак моя спроба співвіднести ці два набори часових позначок (з використанням виводу з uptime) дала розбіжність приблизно в 5000 секунд.

Це приблизно час, за який мій комп'ютер був призупинений.

Чи є зручний спосіб відображення числових часових позначок, використовуваних dmesg та Xorg, в абсолютні часові позначки?

оновлення

Як попередній крок до вирішення цього питання, а також для того, щоб сподіватись, що моє питання буде трохи зрозумілішим, я написав сценарій Python для розбору /var/log/syslogта виведення часу на перекос. На моїй машині, що працює у ubuntu 10.10, цей файл містить численні рядки, що походять з ядра, які штампуються як часовою міткою dmesg, так і часовою міткою syslog. Сценарій виводить рядок для кожного рядка у цьому файлі, який містить часову позначку ядра.

Використання:

python syslogdriver.py /var/log/syslog | column -nts $'\t'

Вихідний вихід (див. Нижче для визначення стовпців):

abs              abs_since_boot  rel_time      rel_offset  message
Jan 13 07:49:15  32842.1276569   32842.301498  0           malkovich malkovich

... rel_offsetстановить 0 для всіх проміжних ліній ...

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становить -5280 для всіх рядків, що залишилися ...

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

... Фінальні лінії знаходяться трохи далі, все ще значно вище кінця виходу. Деякі з них, ймовірно, були записані в dmesgциркулярний буфер до того, як призупинення трапилося, і лише syslogпісля цього їх поширювали . Це пояснює, чому всі вони мають однакову часову позначку syslog.

Визначення стовпців:

abs - час, зареєстрований системою syslog.

abs_since_boot- це той самий час у секундах з моменту запуску системи, виходячи із вмісту /proc/uptimeта значення time.time().

rel_time є часовою міткою ядра.

rel_offset- різниця між abs_since_bootі rel_time. Я округляю це до десятків секунд, щоб уникнути одноразових помилок через абсолютні (тобто syslog-генеровані) часові позначки лише з секундами точністю. Це насправді не правильний спосіб зробити це, оскільки це дійсно (я думаю ..) просто призводить до менших шансів виникнення помилки поза 10. Якщо хтось має кращу ідею, будь ласка, дайте мені знати.

У мене також є деякі питання щодо формату дати syslog; зокрема, мені цікаво, чи з’явиться рік у ньому. Я гадаю, що ні, і в будь-якому випадку, швидше за все, я міг би допомогти мені в цій інформації в TFM, але якщо хтось знає, це буде корисно. .. Звичайно, припускаючи, що хтось використовує цей скрипт у якийсь момент майбутнього, а не просто перериває пару рядків коду Perl.

Далі:

Отже, якщо мені не дасть якихось привітань одкровення, наступним моїм кроком буде додавання функції, щоб отримати перекос часу для заданої часової позначки ядра. Я повинен бути в змозі подати сценарій одним або набором системних журналів разом із часовою міткою ядра, щоб отримати абсолютну мітку часу. Тоді я можу повернутися до налагодження моїх проблем Xorg, які покинуть мене.

Цікава проблема, Не впевнений, що коли-небудь намагався це зробити. Але я помітив часові позначки, про які ви говорите, і я завжди вірив, що це секунди з моменту завантаження.

У своєму системному журналі, який я маю на своєму сервері, у мене є:

Jan 10 19:58:55 wdgitial kernel: [    0.000000] Initializing cgroup subsys cpuset
Jan 10 19:58:55 wdgitial kernel: [    0.000000] Initializing cgroup subsys cpu
Jan 10 19:58:55 wdgitial kernel: [    0.000000] Linux version 2.6.32-21-server (buildd@yellow) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu SMP Fri Apr 16     09:17:34 UTC 2010 (Ubuntu 2.6.32-21.32-server 2.6.32.11+drm33.2)
Jan 10 19:58:55 wdgitial kernel: [    0.000000] Command line:  root=/dev/xvda1 ro quiet splash

Я думаю, що це досить послідовно серед більшості дистрибутивів Linux, оскільки це ядро, що випльовує його речі.

І ось у мене дата разом із часовою позначкою.

Ви можете спробувати:

По-перше, отримайте мітку часу файлу dmesg (моє припущення, це буде час dmesg 0). Ви будете використовувати

ls -l --time-style = +% s

/var/log$ ls -l --time-style=+%s dmesg
-rw-r----- 1 root adm 56181 1294941018 dmesg

Ви можете перетворити секунди в читану людиною дату за допомогою

perl -e 'print scalar localtime(1294941018)' 

Отже, щоб побачити читаний час події, додайте в dmesg секунди від події. Якщо подія dmesg становила 55,290387 секунд, додайте 55 або 55,290387:

perl -e 'print scalar localtime(1294953978 + 55)'

Іншим способом перетворення епохально-укорінених секунд у читабельний час є використання дати -d, як пропонується. Якщо ви скажете "дата", щоб відобразити час, що постачається з -d, ви можете вказати, що час, який потрібно перетворити, відбувається за секунди з моменту епохи, використовуючи @.

date -d "@1294953978"

Це дає вам щось на зразок "Чт 13 січня 15:26:18 CST 2011" як вихід.

дата +% s

Я не можу пригадати, як робити математику оболонок, тому зазвичай використовую метод perl, як описано вище. :)

Найпростіший спосіб зіставити число від dmesg до дати - це використання dateпрограми.

date -d "-50595 seconds"

Ця команда відображає дату поточного часу мінус 50595 секунд.

Від man date:

-d, --date=STRING
       display time described by STRING, not `now'

Число дорівнює часу включення, а не часу, що минув з часу завантаження.

Оскільки ви зазначили, що під час призупинення / резюме змінилося перекос часу, я зазначу, що це зафіксовано хоча б в одному місці. На сторінці man dmesg (1) написано:

Джерело часу, яке використовується для журналів, не оновлюється після системи SUSPEND / RESUME.

Я не зміг знайти спосіб змусити ядро ​​підтримувати ці часові позначки в синхронізації зі часом стіни.

Швидкий, брудний, працює.

$ dmesg | grep 3w | perl /root/print_time_offset.pl

Зміст цього сценарію:

$ cat /root/print_time_offset.pl

#!/usr/bin/perl

$uptime = `cat /proc/uptime | awk '{print $1}';`;
$boot = time() - $uptime;
chomp $boot;
while (<STDIN>) {
        if ($_ =~ /^\[([\s\d\.]+)\]/) {
                $time_offset = $1;
        }
        $real_time = sprintf scalar localtime($boot + $time_offset);
        $_ =~ s/\[[\s\d\.]+\]/\[$real_time\]/;
        print $_;
}

Вибір вибірки такий:

[Mon Feb 21 23:06:33 2011] 3ware 9000 Storage Controller device driver for Linux v2.26.02.012.
[Mon Feb 21 23:06:33 2011] 3w-9xxx 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[Mon Feb 21 23:06:33 2011] 3w-9xxx 0000:03:00.0: setting latency timer to 64
[Mon Feb 21 23:06:33 2011] scsi4 : 3ware 9000 Storage Controller
[Mon Feb 21 23:06:33 2011] 3w-9xxx: scsi4: Found a 3ware 9000 Storage Controller at 0xfbcde000, IRQ: 16.
[Mon Feb 21 23:06:34 2011] 3w-9xxx: scsi4: Firmware FE9X 4.08.00.006, BIOS BE9X 4.08.00.001, Ports: 4.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Sat Feb 26 02:01:01 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=1.
[Sat Feb 26 02:01:01 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=0.
[Sat Feb 26 16:49:13 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=1.
[Sat Feb 26 17:07:19 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=0.
[Sat Mar  5 02:00:16 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=1.
[Sat Mar  5 02:00:16 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=0.
[Sat Mar  5 18:48:57 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=1.
[Sat Mar  5 19:05:17 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=0.
[Sat Mar 12 02:00:30 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=1.
[Sat Mar 12 02:00:30 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=0.