timer.c:331: fatal error: RUNTIME_CHECK(isc_time_no w((&now)) == 0) failed
Posting this because all I found on line were multiple links to a single google post about this error.
On a RHEL5.10 system this morning I did a "dig" and got the error:
timer.c:331: fatal error: RUNTIME_CHECK(isc_time_now((&now)) == 0) failed
Clearly the message is related to time and in the US this past weekend we switched to daylight saving time (in my case we went from EST to EDT). Initially I thought it was because the system I was on didn't do the time change owing to having the incorrect timezone stored in /etc/localtime.
However on doing "zdump -v /etc/localtime |grep 2015" it output the following:
/etc/localtime Sun Mar 8 06:59:59 2015 UTC = Sun Mar 8 01:59:59 2015 EST isdst=0 gmtoff=-18000
/etc/localtime Sun Mar 8 07:00:00 2015 UTC = Sun Mar 8 03:00:00 2015 EDT isdst=1 gmtoff=-14400
/etc/localtime Sun Nov 1 05:59:59 2015 UTC = Sun Nov 1 01:59:59 2015 EDT isdst=1 gmtoff=-14400
/etc/localtime Sun Nov 1 06:00:00 2015 UTC = Sun Nov 1 01:00:00 2015 EST isdst=0 gmtoff=-18000
That confirms it has the correct date and time at which to switch.
I ran "date" and it shows my time is correct but zone is shown as EST when it should show EDT.
We had an issue over the weekend where our GPS ntp clocks weren't updating so I thought perhaps it didn't like that even though ntpd was running. Accordingly I tried to stop that with "service ntpd stop" but this hung on shutdown so I had to ctrl-C out. After that status shows it down but the PID file still existed. Running the stop again "FAILED" but removed the PID file and after that status shows it down.
Stopping ntpd didn't help.
I tried going to the GUI to verify what it had timezone set to there but my console wasn't displaying. Running "shutdown -r 0" from my PuTTY session started the shutdown but it wasn't proceeding (and I couldn't see why because of lack of console). Due to this I power cycled the system.
On power cycle the console began working and during the boot I saw it correctly set the time to current time with EDT zone.
It appears the issue was never ntp but rather something more global impacting operations on this workstation.
On a RHEL5.10 system this morning I did a "dig" and got the error:
timer.c:331: fatal error: RUNTIME_CHECK(isc_time_now((&now)) == 0) failed
Clearly the message is related to time and in the US this past weekend we switched to daylight saving time (in my case we went from EST to EDT). Initially I thought it was because the system I was on didn't do the time change owing to having the incorrect timezone stored in /etc/localtime.
However on doing "zdump -v /etc/localtime |grep 2015" it output the following:
/etc/localtime Sun Mar 8 06:59:59 2015 UTC = Sun Mar 8 01:59:59 2015 EST isdst=0 gmtoff=-18000
/etc/localtime Sun Mar 8 07:00:00 2015 UTC = Sun Mar 8 03:00:00 2015 EDT isdst=1 gmtoff=-14400
/etc/localtime Sun Nov 1 05:59:59 2015 UTC = Sun Nov 1 01:59:59 2015 EDT isdst=1 gmtoff=-14400
/etc/localtime Sun Nov 1 06:00:00 2015 UTC = Sun Nov 1 01:00:00 2015 EST isdst=0 gmtoff=-18000
That confirms it has the correct date and time at which to switch.
I ran "date" and it shows my time is correct but zone is shown as EST when it should show EDT.
We had an issue over the weekend where our GPS ntp clocks weren't updating so I thought perhaps it didn't like that even though ntpd was running. Accordingly I tried to stop that with "service ntpd stop" but this hung on shutdown so I had to ctrl-C out. After that status shows it down but the PID file still existed. Running the stop again "FAILED" but removed the PID file and after that status shows it down.
Stopping ntpd didn't help.
I tried going to the GUI to verify what it had timezone set to there but my console wasn't displaying. Running "shutdown -r 0" from my PuTTY session started the shutdown but it wasn't proceeding (and I couldn't see why because of lack of console). Due to this I power cycled the system.
On power cycle the console began working and during the boot I saw it correctly set the time to current time with EDT zone.
It appears the issue was never ntp but rather something more global impacting operations on this workstation.
Total Comments 0
