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…