No, I’m not going to run 42 kilometres jumping 🙂 I’ve started my leap second tests today. The goal of the tests is to find a configuration, or a procedure, or both, to avoid a backwards step of the clock at the insertion of the leap second at the end of June 30th (UTC).
I ran the first test today. In the ntpd configuration I set two directives:
tinker step 0 and
disable kernel. The first directive disables step adjustments, the latter disables the kernel discipline: ntpd will manage the clock all by itself instead of “asking” the kernel to make corrections to the clock speed; it is not really necessary as the first one should be enough to automatically disable the kernel discipline, so it’s there just for good measure.
So I installed the leap seconds file, installed the new configuration for ntpd, reset the clock to June 30th, 2015 and started the test. For the whole duration of the test the leap second was never armed in the kernel. Everything went as planned in Debian Jessie:
2015/06/30 23:59:59.998489934 2015/06/30 23:59:59.999009849 2015/06/30 23:59:59.999536585 2015/07/01 00:00:00.000063781 2015/07/01 00:00:00.000589560 2015/07/01 00:00:00.001109634
but not so in Wheezy:
2015/06/30 23:59:59.998049126 2015/06/30 23:59:59.998788657 2015/06/30 23:59:59.999572132 2015/07/01 00:00:00.000316483 2015/07/01 00:00:00.001051262 2015/07/01 00:00:00.001792934 2015/07/01 00:00:00.002529339 2015/06/30 23:59:59.004499757 2015/06/30 23:59:59.005266331 2015/06/30 23:59:59.006014975
That means that for wheezy we have two possible “branches”:
- it was ntpd to request the step back
- it was the kernel to request the step back.
The second case is, of course, unlikely as the kernel didn’t know about a leap second. Therefore, the branch to follow first is to use the same ntpd as in jessie in wheezy and see if the results match or not. I’ll keep you posted. Take care.
Update: apparently jessie and wheezy sport the same version of ntpd. Oh well…