43

The BBC reports:

An extra second will be added to the world's clocks on New Year's Eve in order to stay in sync with the Earth's rotation.

Does this mean that I have to do anything so that my Ubuntu machine keeps in time with this or will it automatically adjust itself to not be a second off?

Kaz Wolfe
  • 34,122
  • 21
  • 114
  • 172

2 Answers2

34

If your Ubuntu machine listens to NTP and synchronizes time with the Internet, the system will automatically adjust itself for the difference in time.

While your computer might not necessarily be aware of the fact that a leap second happened, it will catch and record the event as NTP servers push the change throughout the internet.

If you don't feel like the extra second is being added, you can force an update using the following command:

sudo ntpdate -s pool.ntp.org

This will automatically perform geo-location to give you a nearby server (reducing the latency error) and Ubuntu will adjust for your timezone (so if the server is in a different timezone, it's still all okay). Alternatively, you can use ntp.ubuntu.com.

Note that if you're very unlucky, none of the time servers you're using will handle the leap second correctly. It's unlikely, but possible. Checking manually against a known good source (analogue radio, possibly time.is) is advised.

Alternatively, if you're on a modern version of Ubuntu, there's a built in utility called timedatectl. By default, this runs once automatically on startup. Therefore, a quick reboot can force a sync if necessary.

Community
  • 1
Kaz Wolfe
  • 34,122
  • 21
  • 114
  • 172
  • 1
    In the U.K., using time.nist.gov still works. Ubuntu adjusts what it reports for my timezone. I assume the same is true for all time zones – Tim Jan 01 '17 at 13:59
  • 2
    @Tim Yes, but synching with a server in the US has higher latency = higher error rate... so it works, but the end result is less precise than with using a closer server. – Bakuriu Jan 01 '17 at 15:19
  • 1
    Try pool.ntp.org instead; this should always pick up something relatively close to you. – Michael Hampton Jan 01 '17 at 18:09
  • 3
    This answer is problematic. 1.) If you're very unlucky, none of the time servers you'll using will handle the leap second correctly. It's unlikely, but possible. 2.) If ntpd is running, running ntpdate simultaneously will confuse it. Better to stop it first. Better yet, don't run ntpdate at all. 3.) The NIST time servers don't need extra traffic from Stack Exchange; ntp.ubuntu.com or pool.ntp.org would be better. 4.) The UK actually uses uk.pool.ntp.org, but pool.ntp.org will perform geolocation anyway. – Matt Nordhoff Jan 01 '17 at 22:37
  • I forgot one. 5.) If you're running ntpdate against random time servers, and you're very unlucky again, you'll use one that also failed to handle the leap second correctly! The NTP Pool deactivates such servers quickly, but not instantly. And prominent government servers aren't any better. (Though i think the NIST ones were this time.) – Matt Nordhoff Jan 01 '17 at 22:41
17

Leap seconds are handled automatically by the Linux kernel, no reboot or NTP sync is required to keep actual time. If you look in your system log, you will see something similar to

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

Since 23:59:60 is not a valid Linux time, your clock will reach 00:00:00, then step back to 23:59:59. Any objects created during that second (like files) can be dated inconsistently.

As far as Linux time (as opposed to real time) is concerned, leap seconds don't exist:

# date -d "2016-12-31 23:59:59" +%s
1483225199
# date -d "2017-01-01 00:00:00" +%s
1483225200
Kaz Wolfe
  • 34,122
  • 21
  • 114
  • 172
Dmitry Grigoryev
  • 1,942
  • sudo cat /var/log/syslog | grep leap has no output on either my local machine or VPS. Local machine was off at local midnight, probably off at UTC midnight, and VPS was on entire time. Both are 16.04. Any idea why? – Nateowami Jan 01 '17 at 08:07
  • 2
    My logs do appear to confirm this answer. I recently ran dmesg | grep 'leap second' on my main 16.04 machine and it showed [1153894.866672] Clock: inserting leap second 23:59:60 UTC. This, just with different numbers at the beginning, was also shown on my minimal 16.04 VM, installed from mini.iso, that I use for testing. That minimal system does not have ntpd running, nor does it have either of the ntp or openntpd packages installed. – Eliah Kagan Jan 01 '17 at 09:03
  • I have checked both /var/log/syslog and dmesg, and there is no mention of anything like this. –  Jan 01 '17 at 10:09
  • 2
    @EliahKagan Surely the kernel does not have a list of all future leap seconds hardcoded. The kernel has the logic to insert the leap second, but something must tell the kernel that a leap second is to be inserted. I don't know of anything other than NTP which can tell the kernel to insert a leap second. Notice that if the kernel has already been instructed to insert a leap second, then uninstalling NTP without rebooting will leave the kernel in a state where it will insert a leap second. – kasperd Jan 01 '17 at 13:25
  • @kasperd Yep, no software can have a hardcoded list of leap seconds which can't be scheduled far into the future. – Dmitry Grigoryev Jan 01 '17 at 14:00
  • 1
    @kasperd I agree with your general reasoning, but I don't think NTP has ever been installed in that system, which I set up just a few (though more than one) days earlier. Two possibilities come to my mind. This is a VMware virtual machine, and though I haven't installed any VMware drivers, I believe Ubuntu already has some. Might such a driver have found out about the leap second from the host machine? Aside from that, I expect NTP was involved during installation, though I'm not sure how that was made to work across reboots. I think mini.iso itself has NTP and that debian-installer uses it. – Eliah Kagan Jan 01 '17 at 14:26
  • @EliahKagan Good question. I don't know the answer. I believe a VM can get more accurate time keeping with lower overhead if only the host runs NTP and the VM has access to query the time of the host system. I don't know whether such a thing has been implemented, but it certainly is a possibility. – kasperd Jan 01 '17 at 18:43
  • 1
    @EliahKagan, I did not check, but the default ntp client may be chrony. – Carsten S Jan 02 '17 at 09:05
  • 1
    It depends on the configuration of the NTP client whether leap seconds are handled as such or if the clock is simply slowed down. https://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-leap-seconds-ntp/ – Carsten S Jan 02 '17 at 09:08
  • 2
    @CarstenS It turns out systemd-timesyncd(8) has been synchronizing my minimal system's clock. I hadn't thought of this, and found out by semi-accident: grep -RPis '(?<!mou)ntp' /var/log revealed these 14 syslog lines, showing time syncs from a host that happens to have ntp in its name. In hindsight, it makes sense that the mysterious service I never knew I had was part of systemd. (Btw, good point about chrony, which I hadn't checked for either; it's not installed, though.) – Eliah Kagan Jan 02 '17 at 16:09
  • Although I believe that the additional leap second was incremented, I never found anything as is described in the answer in my logs. So not sure about this. –  Mar 01 '17 at 19:54
  • @ParanoidPanda maybe your system is configured to use clock slew rather than step (ntp -x or leapsecmode=slew in chrony)? I'm not sure which messages (if any) appear in the log in the clock slew case. – Dmitry Grigoryev Mar 02 '17 at 08:33