☰

dmesg 中的日期/时间错误

tag-icon • tag-icon centos5 rhel5 timestamp dmesg
dmesg 中的日期/时间错误

我们遇到了一个奇怪的问题。我们使用 perl 脚本在 dmesg 中获取人类可读的时间戳（取自http://linuxaria.com/article/how-to-make-dmesg-timestamp-human-readable）我也试过这个（http://jmorano.moretrix.com/2012/03/dmesg-human-readable-timestamps/）

但记录的时间与系统时间有很大差异，在某些服务器上甚至相差一年：

（我们使用 RHEL 5.8，所以 dmesg -T 这里不是一个选项）

例如：DB1：

  [root@dbXX ~]# echo "Test dmesg message" > /dev/kmsg 
  [root@dbXX ~]# /opt/ns/scripts/dmesg | tail -10
  [2015-01-17 07:23:09]  kjournald starting.  Commit interval 5 seconds
  [2015-01-17 07:23:09]  EXT3 FS on cciss/c0d1p1, internal journal
  [2015-01-17 07:23:09]  EXT3-fs: mounted filesystem with ordered data mode.
  [2015-01-20 05:54:18]  kjournald starting.  Commit interval 5 seconds
  [2015-01-20 05:54:18]  EXT3 FS on cciss/c0d1p1, internal journal
  [2015-01-20 05:54:18]  EXT3-fs: mounted filesystem with ordered data mode.
  [2015-01-20 06:19:19]  kjournald starting.  Commit interval 5 seconds
  [2015-01-20 06:19:19]  EXT3 FS on cciss/c0d1p1, internal journal
  [2015-01-20 06:19:19]  EXT3-fs: mounted filesystem with ordered data mode.
  [2014-09-23 10:28:35]  Test dmesg message
  [root@dbXX ~]# date
  Mon Apr 20 06:22:44 PDT 2015
  [root@dbXX ~]# hwclock --show 
  Mon 20 Apr 2015 06:22:56 AM PDT  -0.790126 seconds

DB2：

[root@dbXXYY ~]# echo "Test dmesg message" > /dev/kmsg 
[root@dbXXYY ~]# /opt/ns/scripts/dmesg | tail -10
[2014-01-27 04:43:46]   [<ffffffff8002cafd>] mntput_no_expire+0x19/0x89
[2014-01-27 04:43:46]   [<ffffffff80063c63>] __mutex_lock_slowpath+0x60/0x9b
[2014-01-27 04:43:46]   [<ffffffff8002380c>] __path_lookup_intent_open+0x56/0x97
[2014-01-27 04:43:46]   [<ffffffff80063cad>] .text.lock.mutex+0xf/0x14
[2014-01-27 04:43:46]   [<ffffffff8001b15e>] open_namei+0xea/0x6ba
[2014-01-27 04:43:46]   [<ffffffff800275c8>] do_filp_open+0x1c/0x38
[2014-01-27 04:43:46]   [<ffffffff80019f9a>] do_sys_open+0x44/0xbe
[2014-01-27 04:43:46]   [<ffffffff8005d116>] system_call+0x7e/0x83
[2014-01-27 04:43:46]  
[2014-02-28 10:27:28]  Test dmesg message
[root@dbXXYY ~]# date
Mon Apr 20 06:24:13 PDT 2015
[root@dbXXYY ~]# hwclock --show
Mon 20 Apr 2015 05:24:17 AM PDT  -0.344776 seconds

DB3：

[root@dbYY ~]# echo "Test dmesg message" > /dev/kmsg 
[root@dbYY ~]# /opt/ns/scripts/dmesg | tail -10
[2015-01-12 01:04:45]  
[2015-02-02 11:11:44]  request_module: runaway loop modprobe net-pf-10
[2015-02-02 11:11:44]  request_module: runaway loop modprobe net-pf-10
[2015-02-02 11:11:44]  request_module: runaway loop modprobe net-pf-10
[2015-02-02 11:11:44]  request_module: runaway loop modprobe net-pf-10
[2015-02-02 11:11:44]  request_module: runaway loop modprobe net-pf-10
[2015-04-20 02:28:30]  Test dmesg message
[root@dbYY  ~]# date
Mon Apr 20 06:16:08 PDT 2015
[root@dbYY  ~]# hwclock --show
Mon 20 Apr 2015 05:16:58 AM PDT  -0.634708 seconds

知道如何纠正吗？提前致谢

答案1

尝试“journalctl -k”而不是“dmesg”

细节：https://serverfault.com/a/1083381/189414

答案2

最近，我租了一个云 VPS。当我登录时，日期是格林威治标准时间 (GMT)。我将其更改为 CDT，即 UTC-5:00。我很快意识到，尽管 date 命令确实输出了正确的时间和日期，但 syslogd 控制的日志却偏离了 5 个小时。它们仍在使用格林威治标准时间 (GMT)。我当时没有做任何事情，因为我不需要精确的时间/日期记录，而且我知道重新启动可能会解决这个问题，但我无法立即执行此操作，因为它是一台生产服务器。

为了对 VPS 进行完整备份，我安排了一次维护性关闭。重启后，syslogd 日志开始以正确的 CDT 时间记录。最重要的是，使用 date 命令确保您的服务器具有正确的时间/日期/时区，并尽快重启这些服务器。

顺便说一句，我认为 #date 时间/日期 和 #hwclock 时间/日期 之间相差一小时是由于夏令时时区变化造成的。看来硬件时钟时间确实改变了时区，但实际上并没有改变日期。

相关内容