# "kernel time" is about fifteen minutes in the future

## curmudgeon

I have never seen anything like this before.

Basically, everything from the kernel that goes into the syslog (/var/log/messages) is timestamped with a value about fifteen minutes ahead of the system (and actual) time.

Best to show an example (this was taken at about 21:54):

```

Jun 6 21:50:55 system kernel: CPU3: Core temperature above threshold, cpu clock throttled (total events = 1050404950)

Jun 6 21:50:55 system kernel: CPU3: Core temperature/speed normal

Jun 6 21:52:09 system kernel: mce: [Hardware Error]: Machine check events logged

Jun 6 21:36:42 system mcelog[23558]: Processor 3 heated above trip temperature. Throttling enabled.

Jun 6 21:36:42 system mcelog[23558]: Please check your system cooling. Performance will be impacted

Jun 6 21:36:42 system mcelog[23558]: Processor 3 below trip temperature. Throttling disabled

Jun 6 21:58:46 system kernel: CPU1: Core temperature above threshold, cpu clock throttled (total events = 1051624272)

Jun 6 21:58:46 system kernel: CPU1: Core temperature/speed normal

Jun 6 21:59:39 system kernel: mce: [Hardware Error]: Machine check events logged

Jun 6 21:44:12 system mcelog[23558]: Processor 1 heated above trip temperature. Throttling enabled.

Jun 6 21:44:12 system mcelog[23558]: Please check your system cooling. Performance will be impacted

Jun 6 21:44:12 system mcelog[23558]: Processor 1 below trip temperature. Throttling disabled

Jun 6 22:03:46 system kernel: CPU1: Core temperature above threshold, cpu clock throttled (total events = 1051658749)

Jun 6 22:03:46 system kernel: CPU1: Core temperature/speed normal

Jun 6 22:04:40 system kernel: mce: [Hardware Error]: Machine check events logged

Jun 6 21:49:13 system mcelog[23558]: Processor 1 heated above trip temperature. Throttling enabled.

Jun 6 21:49:13 system mcelog[23558]: Please check your system cooling. Performance will be impacted

Jun 6 21:49:13 system mcelog[23558]: Processor 1 below trip temperature. Throttling disabled

Jun 6 22:08:46 system kernel: CPU1: Core temperature above threshold, cpu clock throttled (total events = 1051699850)

Jun 6 22:08:46 system kernel: CPU1: Core temperature/speed normal

```

The machine is a timeserver (the system time is within two milliseconds of its peers according to ntpq), so the system time is spot on. I just don't know where the timestamps from the kernel generated messages are coming from (but whatever the source is, it is quite wrong).

----------

## NeddySeagoon

curmudgeon,

Check the timezone.  Your clock will be running at UTC.

Displayed times will be corrected by the timezone.

If /etc/timezone is correct, try another timezone.  Maybe there is a problem just with the timezone file you are actually using.

----------

## haarp

It could also be that syslog-ng is showing wrong timestamps for kernel messages. This seems to be happening a lot lately.

----------

## toralf

 *haarp wrote:*   

> It could also be that syslog-ng is showing wrong timestamps for kernel messages. This seems to be happening a lot lately.

 with 3.6.2 and if the system was suspened/resumed.

3.6.3 is fine so far.

----------

## Buffoon

Can your kernel predict lotto numbers?   :Razz: 

----------

## cal22cal

hwclock ?

http://docs.slackware.com/howtos:hardware:syncing_hardware_clock_and_system_local_time

----------

## charles17

 *curmudgeon wrote:*   

> The machine is a timeserver (the system time is within two milliseconds of its peers according to ntpq), so the system time is spot on. I just don't know where the timestamps from the kernel generated messages are coming from (but whatever the source is, it is quite wrong).

 

Did you compare that timestamp to hwclock?

```
# /sbin/hwclock && date
```

----------

## mjbjr

I've been following this thread because I have the same problem,

except that my kernel log message timestamps are four minutes

ahead of all the clocks.  All the clocks are accurate.

hw clock (UTC)

linux system clock (UTC)

local (xfce4 desktop) (PDT)

I've never had this problem before, afaicr.

----------

## curmudgeon

I had to reboot a while back (which resynced everything), and the problem has not returned. 

Thanks for the suggestions, but all my computers use UTC anyway, and it wasn't the hardware clock (syslog-ng wouldn't be using the hardware clock anyway). Maybe this was just a bad version of syslog-ng (I see some other people have noticed the same problem, so at least I am not imagining things).

I have upgraded to syslog-ng 3.6.4 (which fixed some other problems), and I hope that this one won't return.

----------

