[time-nuts] Leap Quirks

Magnus Danielson magnus at rubidium.dyndns.org
Sat Jan 3 16:09:39 UTC 2009


Chuck Harris skrev:
> christopher hoover wrote:
>> Hal Murray wrote: 
>>> Two of my Linux systems hung.  One was running a 2.6.25 kernel and one
>>> 2.6.26.  A system running 2.6.23 worked fine.  I saw a couple of notes
>>> on
>>> comp.protocols.time.ntp about Linux systems locking up.  One said that
>>> it was
>>> a kernel bug in ntp.c but I haven't seen any details.
>> None of mine (many dozens) hung.    This is typical:
>>
>> ch at snaggle:~$ uname -a
>> Linux snaggle.murgatroid.com 2.6.26-1-amd64 #1 SMP Mon Dec 15 19:40:58 UTC
>> 2008 x86_64 GNU/Linux
>> ch at snaggle:~$ dmesg | grep leap 
>> [844362.415072] Clock: inserting leap second 23:59:60 UTC
>> ch at snaggle:~$
>>
>>
>> -ch
> 
> None of my linux systems hung either!  My typical message was:
> 
> $ dmesg | grep leap
> [6181904.453104] Clock: inserting leap second 23:59:60 UTC
> 
> The message implies that linux clocks counted:
> 
> 58..59..60..00..01
> 
> Which would not be the POSIX way.

I just checked. Two of my linux machines happilly chewed on and they 
both display the same thing

magda-gw:/etc# dmesg | grep leap
[3672744.988878] Clock: inserting leap second 23:59:60 UTC

magnus at heaven:~$ dmesg | grep leap
[2382608.682165] Clock: inserting leap second 23:59:60 UTC

I have not heard any screems of terror from my neck of the woods either.
So what ever it is, few was actually affected.

I am actually curious about where this happens and the answer is found 
in /usr/src/linux-source-2.6.26/kernel/time/ntp.c:

/*
  * Leap second processing. If in leap-insert state at the end of the
  * day, the system clock is set back one second; if in leap-delete
  * state, the system clock is set ahead one second.
  */
static enum hrtimer_restart ntp_leap_second(struct hrtimer *timer)
{
         enum hrtimer_restart res = HRTIMER_NORESTART;

         write_seqlock_irq(&xtime_lock);

         switch (time_state) {
         case TIME_OK:
                 break;
         case TIME_INS:
                 xtime.tv_sec--;
                 wall_to_monotonic.tv_sec++;
                 time_state = TIME_OOP;
                 printk(KERN_NOTICE "Clock: "
                        "inserting leap second 23:59:60 UTC\n");
                 leap_timer.expires = ktime_add_ns(leap_timer.expires,
                                                   NSEC_PER_SEC);
                 res = HRTIMER_RESTART;
                 break;
         case TIME_DEL:
                 xtime.tv_sec++;
                 time_tai--;
                 wall_to_monotonic.tv_sec--;
                 time_state = TIME_WAIT;
                 printk(KERN_NOTICE "Clock: "
                        "deleting leap second 23:59:59 UTC\n");
                 break;
         case TIME_OOP:
                 time_tai++;
                 time_state = TIME_WAIT;
                 /* fall through */
         case TIME_WAIT:
                 if (!(time_status & (STA_INS | STA_DEL)))
                         time_state = TIME_OK;
                 break;
         }
         update_vsyscall(&xtime, clock);

         write_sequnlock_irq(&xtime_lock);

         return res;
}

So the log message 23:59:60 is actually static value. This mechanism is 
what Dave Mills describes on his NTP page. The time calculations 
otherwise follow POSIX.

Cheers,
Magnus




More information about the Time-nuts_lists.febo.com mailing list