Description of problem: On ia64 and ppc architectures leap second isn't inserted (on x86_64, i386 and s390 it seems to work fine). In syslog there is message kernel: Clock: inserting leap second 23:59:60 UTC but comparing the clock against an NTP server shows that it wasn't inserted. Version-Release number of selected component (if applicable): kernel-2.6.18-92.el5 How reproducible: Always Steps to Reproduce: 1. select an NTP server 2. date -s "2008/12/31 23:59:55 UTC"; ntptime -s 16; ntpdate -q $ntpserver; sleep 10; ntpdate -q $ntpserver; ntptime -s 64; ntpdate $ntpserver Actual results: No or very small difference between the offsets printed by ntpdate -q commands. Expected results: 1 second difference. Additional info:
Well, since the leap second has come and gone, I don't think this is a bug anymore :) P.
I'm pretty sure this wasn't the last one. They are usually announced 6 months before the event, so there should be some room to make a fix. Would be good to keep this open, with very low priority for now.
Miroslav, I'm not that familiar with the output from ntpdate and ntptime, so I'm not sure exactly what looks strange or what is showing a small difference in time. I have nec-nx2-1.rhts.bos.redhat.com reserved, with the standard RHTS password. Do you think you could login, run the test, and copy an annotated result into the BZ? That way I would have a better idea of what "looks" wrong. I will note that the "inserting leap second 23:59:60 UTC" message is being output to the console, so at least the code that is supposed to execute is running. TIA Miroslav, and sorry for the extra work, P.
Only output of the first and second ntpdate call is important. The difference between the offsets is -0.000449, but should be around -1.0 seconds. Wed Dec 31 18:59:55 EST 2008 ntp_gettime() returns code 5 (ERROR) time cd0685fb.00860000 Wed, Dec 31 2008 18:59:55.002, (.002045), maximum error 16384000 us, estimated error 16384000 us ntp_adjtime() returns code 0 (OK) modes 0x10 (STATUS), offset 0.000 us, frequency 32.113 ppm, interval 1 s, maximum error 16384000 us, estimated error 16384000 us, status 0x10 (INS), time constant 2, precision 1.000 us, tolerance 512 ppm, server 10.34.33.125, stratum 3, offset 3781593.718461, delay 0.30435 31 Dec 18:59:56 ntpdate[22720]: step time server 10.34.33.125 offset 3781593.718461 sec ^^^ first offset server 10.34.33.125, stratum 3, offset 3781593.718910, delay 0.30293 31 Dec 19:00:08 ntpdate[22787]: step time server 10.34.33.125 offset 3781593.718910 sec ^^^ second offset (after leap second) ntp_gettime() returns code 5 (ERROR) time cd068608.83efe000 Wed, Dec 31 2008 19:00:08.515, (.515379), maximum error 16384000 us, estimated error 16384000 us ntp_adjtime() returns code 5 (ERROR) modes 0x10 (STATUS), offset 0.000 us, frequency 32.113 ppm, interval 1 s, maximum error 16384000 us, estimated error 16384000 us, status 0x40 (UNSYNC), time constant 2, precision 1.000 us, tolerance 512 ppm, 31 Dec 19:00:08 ntpdate[22797]: the NTP socket is in use, exiting
This likely isn't going to be fixed for RHEL5. Closing as WONTFIX. P.