web-dev-qa-db-ja.com

/ 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タイムスタンプの両方でスタンプされた、カーネルが生成した多数の行が含まれています。スクリプトは、カーネルタイムスタンプを含むそのファイルの各行の行を出力します。

使用法：

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

また、syslogの日付形式についても質問があります。特に、一年がそこに表れるのではないかと思います。私はそうではないと思います。いずれにせよ、TFMでその情報に自分自身を助ける可能性が最も高いのですが、誰かがたまたま知っていれば、それは役に立つでしょう。 ..もちろん、Perlコードの数行をバスアウトするのではなく、誰かが将来このスクリプトを使用すると仮定します。

次：

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

linuxxorglogstimestamps
20
intuited

興味深い問題です。これを試したことがあるかどうかはわかりません。しかし、私はあなたが話しているタイムスタンプに気づきました、そして私はいつもそれがブートアップから数秒であると信じていました。

私のサーバーにある私の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ディストリビューション間でかなり一貫していると思います。これは、カーネルがそれを吐き出すカーネルだからです。

そして、ここにタイムスタンプと一緒に日付があります。

4
Ryan Gibbons

あなたはこれを試してみることができます：

まず、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を使用することです。 'date'に-dで指定された時刻を表すように指示する場合、@を使用して、変換される時刻がエポック以降の秒であることを示すことができます。

date -d "@1294953978"

これにより、「木1月13日15:26:18 CST 2011」のような出力が得られます。

日付+％s

シェルの計算方法を思い出せないので、通常は上記のようにPerlメソッドを使用します。 :)

3
belacqua

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

システムのSUSPEND/RESUMEの後、ログに使用されるタイムソースは更新されません。

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

2
Andrew

Dmesgから日付に数値をマッピングする最も簡単な方法は、dateプログラムを使用することです。

date -d "-50595 seconds"

このコマンドは、現在時刻から50595秒を引いた日付を表示します。

man dateから：

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

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

2
Lekensteyn

すばやく、汚れて、動作します。

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