0

we have this strange issue. We use perl script for human-readable time-stamp in dmesg (taken from http://linuxaria.com/article/how-to-make-dmesg-timestamp-human-readable) and I also tried this one ( http://jmorano.moretrix.com/2012/03/dmesg-human-readable-timestamps/ )

but the time of the records is very different from system time, on some servers even a year :

(We use RHEL 5.8 so dmesg -T is not a option here)

Example: 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

Any idea how to correct that? Thanks in advance

Hudsik
  • 1
  • 2

2 Answers2

1

Try "journalctl -k" instead of "dmesg"

Details: https://serverfault.com/a/1083381/189414

16851556
  • 386
  • 2
  • 5
  • 18
1

Recently, I rented a cloud VPS. When I logged into it, the date was on GMT. I changed it to CDT, which is UTC-5:00. I quickly realized that, even though the date command did output the correct time and date, the logs controlled by syslogd were off by five hours. They were still using GMT. I didn't do anything at that time as I needed not precise time/date logging, and I knew that a restart would probably fix it, but I couldn't do it right away as it was a production server.

To make a full backup of the VPS, I scheduled a maintenance shutdown. After the restart, syslogd logs started to be logged with the correct CDT time. Bottom line, make sure your servers have the correct time/date/timezone with the date command and, as soon as you can, restart those servers.

By the way, I think the one hour difference between #date time/date and the #hwclock time/date is due to the Daylight Time timezone change. It seems that the hardware clock time does change the time zone, but does not actually change the date.

AlbertoConradoMX
  • 96
  • 3