1 July 2012.

There was a leap second inserted at the end of June 2012 in UTC (the second before 1341100800 Unix epoch, which is 3550089600 NTP epoch). I watched it happen on several different systems, all of which sync time using ntpd.

Linux, no leapfile

This system is synced to timeservers which are advertising the leap second, but it does not have its own leapfile.

In 2012, I got the leapfile from ftp://tycho.usno.navy.mil/pub/ntp/.
In 2015, I used ftp://time.nist.gov/pub/leap-seconds.3629404800

ntpd variables before the event:

$ ntpq -c rv
associd=0 status=4615 leap_add_sec, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.6p5@1.2349-o Sat May 12 09:54:55 UTC 2012 (1)",
processor="x86_64", system="Linux/3.2.0-2-amd64", leap=01, stratum=3,
precision=-23, rootdelay=188.939, rootdisp=125.721, refid=163.73.58.221,
reftime=d399a552.23661694  Sun, Jul  1 2012  2:18:26.138,
clock=d399a644.106215cf  Sun, Jul  1 2012  2:22:28.063, peer=60722, tc=7,
mintc=3, offset=-8.826, frequency=27.933, sys_jitter=11.106,
clk_jitter=10.861, clk_wander=3.028

I ran a simple program that prints CLOCK_REALTIME and CLOCK_MONOTONIC every 0.1 secs:

1341100797.965 74545.296
1341100798.065 74545.396
1341100798.165 74545.496
1341100798.265 74545.596
1341100798.365 74545.696
1341100798.465 74545.796
1341100798.566 74545.896
1341100798.666 74545.996
1341100798.766 74546.096
1341100798.866 74546.196
1341100798.966 74546.297
1341100799.066 74546.397 ← 799 starts
1341100799.166 74546.497
1341100799.266 74546.597
1341100799.366 74546.697
1341100799.466 74546.797
1341100799.566 74546.897
1341100799.666 74546.997
1341100799.766 74547.097
1341100799.867 74547.197
1341100799.967 74547.297
1341100799.067 74547.397 ← 799 replays!
1341100799.167 74547.497
1341100799.267 74547.598
1341100799.367 74547.698
1341100799.467 74547.798
1341100799.567 74547.898
1341100799.667 74547.998
1341100799.767 74548.098
1341100799.867 74548.198
1341100799.967 74548.298
1341100800.067 74548.398 ← 800
1341100800.168 74548.498
1341100800.268 74548.598
1341100800.368 74548.698
1341100800.468 74548.798
1341100800.568 74548.899
1341100800.668 74548.999
1341100800.768 74549.099
1341100800.868 74549.199
1341100800.968 74549.299
1341100801.068 74549.399

To the best of my understanding, the above is the "correct" POSIX handling of the leap second - the last second before midnight is replayed.

dmesg says:

[74498.634819] Clock: inserting leap second 23:59:60 UTC

(I'm not sure why it's 74498 instead of 74547. The kernel log is uptime and CLOCK_MONOTONIC returns something else?)

ntpd variables after the event:

$ ntpq -c rv
associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event,
version="ntpd 4.2.6p5@1.2349-o Sat May 12 09:54:55 UTC 2012 (1)",
processor="x86_64", system="Linux/3.2.0-2-amd64", leap=00, stratum=3,
precision=-23, rootdelay=33.145, rootdisp=175.777, refid=6.15.154.237,
reftime=d39a49b9.f4d6c58c  Sun, Jul  1 2012 13:59:53.956,
clock=d39a4c69.7ad513bc  Sun, Jul  1 2012 14:11:21.479, peer=60716,
tc=10, mintc=3, offset=0.104, frequency=14.249, sys_jitter=2.417,
clk_jitter=3.037, clk_wander=0.626

Linux again

The second Linux system, a VPS, was configured very much the same as above but syncing against different upstream servers. It behaved the same as above but its peers had some trouble. Before the event:

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*clock.sjc.he.ne .CDMA.           1 u  320 1024  377    0.912    0.249   0.156
+clock.nyc.he.ne .CDMA.           1 u  171 1024  377   71.371    0.218   0.017
+clock.fmt.he.ne .CDMA.           1 u  959 1024  377    0.818    0.198   0.293
-li4-205.members 66.220.9.122     2 u  186 1024  377    0.572    0.846   0.384
 support.rccfo.c 216.218.254.202  2 u  170 1024  377    0.909   -0.003   0.457

After the event:

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+clock.sjc.he.ne LOCAL(0)         4 u  322 1024  377    0.879    0.059   0.143
 clock.nyc.he.ne .STEP.          16 u  182 1024  376   71.325  999.728   0.061
+clock.fmt.he.ne LOCAL(0)         4 u  958 1024  377    0.991    0.144   3.386
+li4-205.members 132.239.1.6      2 u  386 1024  377    0.638    0.205   0.151
*support.rccfo.c 69.25.96.13      2 u  358 1024  377    0.753    0.261   0.186

FreeBSD, with leapfile

Like the first system, this one is also synced to timeservers advertising the leap second, and also has its own local leapfile.

Before the event:

$ ntpq -c rv
assID=0 status=4619 leap_add_sec, sync_ntp, 1 event, event_9,
version="ntpd 4.2.6p5@1.2349-o Sat Jun 30 14:44:34 UTC 2012 (1)",
processor="amd64", system="FreeBSD/9.0-RELEASE-p3", leap=01, stratum=3,
precision=-20, rootdelay=18.933, rootdisp=209.430, refid=130.102.2.123,
reftime=d399a5ab.1d01fbcb  Sun, Jul  1 2012  2:19:55.113,
clock=d399a61f.012f5c51  Sun, Jul  1 2012  2:21:51.004, peer=4026, tc=8,
mintc=3, offset=-1.159, frequency=-7.155, sys_jitter=0.270,
clk_jitter=3.504, clk_wander=0.037, tai=34, leapsec=201207010000,
expire=201212280000

The moment of truth:

1341100797.921 218154.218
1341100798.022 218154.319
1341100798.123 218154.420
1341100798.224 218154.521
1341100798.325 218154.622
1341100798.426 218154.723
1341100798.527 218154.824
1341100798.628 218154.925
1341100798.729 218155.026
1341100798.830 218155.127
1341100798.931 218155.228
1341100799.032 218155.329 ← 799 starts
1341100799.133 218155.430
1341100799.234 218155.531
1341100799.335 218155.632
1341100799.436 218155.733
1341100799.537 218155.834
1341100799.638 218155.935
1341100799.739 218156.036
1341100799.840 218156.137
1341100799.941 218156.238
1341100799.042 218156.339 ← 799 replays
1341100799.143 218156.440
1341100799.244 218156.541
1341100799.345 218156.642
1341100799.446 218156.743
1341100799.547 218156.844
1341100799.648 218156.945
1341100799.749 218157.046
1341100799.850 218157.147
1341100799.951 218157.248
1341100800.052 218157.349
1341100800.153 218157.450
1341100800.254 218157.551
1341100800.355 218157.652
1341100800.456 218157.753
1341100800.557 218157.854
1341100800.658 218157.955
1341100800.759 218158.056
1341100800.860 218158.157
1341100800.961 218158.258
1341100801.062 218158.359

I couldn't find any mention of the leap second in the system logs.

FreeBSD, leap smear

This system is interesting because it's synced only to Google time servers, which "smear" the leap second over a 24-hour period. There's an interesting article describing the leap smear.

Variables before the event don't show a coming leap second:

$ ntpq -c rv
assID=0 status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg,
version="ntpd 4.2.4p5-a (1)", processor="amd64",
system="FreeBSD/9.0-RELEASE", leap=00, stratum=3, precision=-20,
rootdelay=158.435, rootdispersion=449.770, peer=57767,
refid=216.239.32.15,
reftime=d399a5b2.e545f3ab  Sun, Jul  1 2012  2:20:02.895, poll=6,
clock=d399a63c.e0414a61  Sun, Jul  1 2012  2:22:20.875, state=4,
offset=7.909, frequency=-5.790, jitter=29.121, noise=2.796,
stability=0.018, tai=0

And realtime doesn't step backwards:

1341100797.927 506761.306
1341100798.028 506761.407
1341100798.129 506761.508
1341100798.230 506761.609
1341100798.331 506761.710
1341100798.432 506761.811
1341100798.533 506761.912
1341100798.634 506762.013
1341100798.735 506762.114
1341100798.836 506762.215
1341100798.937 506762.316
1341100799.038 506762.417 ← 799
1341100799.139 506762.518
1341100799.240 506762.619
1341100799.341 506762.720
1341100799.442 506762.821
1341100799.543 506762.922
1341100799.644 506763.023
1341100799.745 506763.124
1341100799.846 506763.225
1341100799.947 506763.326
1341100800.048 506763.427 ← 800
1341100800.149 506763.528
1341100800.250 506763.629
1341100800.351 506763.730
1341100800.452 506763.831
1341100800.553 506763.932
1341100800.654 506764.033
1341100800.755 506764.134
1341100800.856 506764.235
1341100800.957 506764.336
1341100801.058 506764.437