/ 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

数字は起動からの秒とマイクロ秒を表していると推測/収集しています。

ただし、これら2つのタイムスタンプのセットを（からの出力を使用してuptime）相関させようとすると、約5000秒の不一致が生じました。

これはおおよそ、コンピューターが中断された時間です。

dmesgとXorgが使用する数値タイムスタンプを絶対タイムスタンプにマップする便利な方法はありますか？

更新

これを理解するための予備ステップとして、また私の質問をもう少し明確にするために、時間のずれを解析して出力するPythonスクリプトを作成しました/var/log/syslog。私のマシンでは、ubuntu 10.10を実行しており、そのファイルにはdmesgタイムスタンプとsyslogタイムスタンプの両方がスタンプされた多数のカーネル由来の行が含まれています。スクリプトは、カーネルタイムスタンプを含むそのファイルの各行に1行を出力します。

使用法：

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秒単位の精度しか持たない絶対的な（つまり、生成された）タイムスタンプによる1回限りのエラーを回避するために、これを数十秒に丸めています。これは実際には正しい方法ではありません。なぜなら、実際には（私は..）10を超えるエラーが発生する可能性が小さくなるからです。誰かがより良いアイデアを持っているなら、私に知らせてください。

syslogの日付形式についても質問があります。特に、1年がその中に現れるかどうか疑問に思っています。私はノーと推測している、とにかくTFMでその情報に役立つ可能性が最も高いかもしれないが、誰かがたまたまそれが有用であることを知っていれば。..もちろん、誰かがこのスクリプトを将来のある時点で使用し、数行のPerlコードを破壊するのではないと仮定します。

次：

だから、あなたからの何らかの歓迎された啓示が私に与えられない限り、私の次のステップは、与えられたカーネルのタイムスタンプの時間のずれを取得する関数を追加することです。絶対タイムスタンプを取得するために、カーネルのタイムスタンプとともに、1つまたは一連のsyslogをスクリプトに送信できる必要があります。その後、Xorgの問題のデバッグに戻ることができますが、これは現時点では回避できます。

興味深い問題、私がこれをやろうとしたことがあるかどうかはわかりません。しかし、私はあなたが話しているタイムスタンプに気づいており、起動から数秒であると信じていました。

サーバーにあるsyslogには、次のものがあります。

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)'

画期的な秒を読み取り可能な時間に変換する別の方法は、提案されているようにdate -dを使用することです。-dで指定された時刻を表すように「日付」を指定した場合、@を使用して、変換される時刻がエポックからの秒数であることを示すことができます。

date -d "@1294953978"

これにより、「Thu Jan 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'

この数値は、起動時からの経過時間ではなく、電源投入時の時間と同じです。

サスペンド/レジューム中に時間のずれが変化することに気付いたので、これは少なくとも1か所で文書化されています。dmesg（1）のマニュアルページには次のように記載されています。

ログに使用されるタイムソースは、システムのサスペンド/再開後に更新されません。

カーネルがこれらのタイムスタンプをウォール時間と同期させる方法を見つけることができませんでした。

早く、汚い、うまくいきます。

$ 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.