[foton1981]

What if I disable ntpd a minute before leap second is injected and restart it a minute later?

[cnvogel]

My guess is, the leap second will be inserted, just as scheduled. And you'll get the famous message in your kernel log (dmesg):

http://lxr.free-electrons.com/source/kernel/time/ntp.c?v=2.6...

    Clock: inserting leap second 23:59:60 UTC

If ntpd gets notified of an impeding leap second via its peers (or the connected radio clock, GPS receiver, ...) it will set (struct timex*)->status |= STA_INS via the timex syscall (which it also uses to steer/speed-up/slow-down the clock).

http://man7.org/linux/man-pages/man2/adjtimex.2.html

The stock linux kernel works such that if ntpd will have set the STA_INS flag via adjtimex some time before, the kernel will do the leap-second insertion at the end of the UTC day.

If you disable ntpd and it doesn't reset this flag (which I doubt it does, but you'd have to check), the kernel will insert the leap second on its own, even if ntpd is not running.

If you disable ntpd, and either ntpd on termination (which I doubt), or you via the adjtimex syscall, clear the STA_INS flag, then the kernel will not insert the leap second. After UTC midnight, the clock will then be one second off, and a restart of ntpd will slowly steer the clock back to correct time.

For playing with all of this, there's a adjtimex tool which can display and even change the timex values:

    ➜  sbin  ./adjtimex -pV | sed 's/^/    /'
             mode: 0
           offset: 0
        frequency: -344608
         maxerror: 16000000
         esterror: 16000000
           status: 64
    time_constant: 2
        precision: 1
        tolerance: 32768000
             tick: 10000
         raw time:  1432018768s 308111us = 1432018768.308111
     return value = 5

[foton1981]

Thanks! that's good info. It helped me to find a good article from someone to devoted couple days on testing this method: http://syslog.me/2012/06/01/an-humble-attempt-to-work-around...