у нас есть эта странная проблема. Мы используем 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 связана с изменением часового пояса летнего времени. Кажется, что время аппаратных часов действительно меняет часовой пояс, но на самом деле не меняет дату.