Назад | Перейти на главную страницу

Неверная дата / время в 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

Есть идеи, как это исправить? заранее спасибо

Недавно арендовал облачный VPS. Когда я вошел в систему, дата была по Гринвичу. Я изменил его на CDT, то есть UTC-5: 00. Я быстро понял, что, хотя команда date выводила правильное время и дату, журналы, управляемые syslogd, были отключены на пять часов. Они все еще использовали GMT. В то время я ничего не делал, так как мне не нужно было регистрировать точное время / дату, и я знал, что перезапуск, вероятно, исправит это, но я не мог сделать это сразу, так как это был рабочий сервер.

Чтобы сделать полную резервную копию VPS, я запланировал выключение для обслуживания. После перезапуска журналы syslogd начали регистрироваться с правильным временем CDT. В итоге убедитесь, что на ваших серверах указано правильное время / дата / часовой пояс с помощью команды date, и, как только вы сможете, перезапустите эти серверы.

Кстати, я думаю, что разница в один час между #date time / date и #hwclock time / date связана с изменением часового пояса летнего времени. Кажется, что время аппаратных часов действительно меняет часовой пояс, но на самом деле не меняет дату.