How is everyone going to handle a leap second added to the end of 2016, for kube-aws created clusters?

[mumoshu]

IFAIK,

• CoreOS uses systemd-timesyncd instead of ntpd or chronyd to sync time, by default.
• It is possible to switch to ntpd as described in the CoreOS doc
• We usually(?) handle leap second with the slew feature which can be seen in ntpd, chronyd
• The slew feature make the leap second invisible and the clock is gradually fixed over time. Theoretically, it will be enough to completely avoid issues from a leap second.

However:

• systemd-timesyncd's slew feature is limited. It applies the slew feature only when the gap of the clock is less than 0.4 sec according to timesyncd's source
• ntpd.service included in coreos-overlay doesn't seem to provide -x -g option to enable "slew" according to coreos-overlay's source

[pieterlange]

I think this is more of an issue for CoreOS upstream.

[mumoshu]

Could be. I wish CoreOS had a guide like RedHat does.

[mumoshu]

You can blame be for doing this but cross posted to the coreos users' group! https://groups.google.com/forum/?hl=ja#!topic/coreos-user/tMaJtso7Ky4

[mumoshu]

Closing this as probably no one is interested 😢

[mumoshu]

Note to self: It turns out we can just source from a leap-smearing NTP server instead of the default one so that a leap is handled on their side.

[aholbreich]

@mumoshu you can source time from google or whatever but that does not prevent your system to include .60 second automatically or? I would not expect that without special treatment

[mumoshu]

@aholbreich Thanks for catching this up 👍
AFAIK, Google Public NTP serves leap-smeared time hence sourcing it ends up making a leap second invisible from our ntp clients and hence our clock.

[aholbreich]

Nice info @mumoshu, found this too now: http://www.theregister.co.uk/2016/12/02/google_public_ntp_servers/

I was thinking if it still has any troubles with tzdata (time zone database) that includes leapseconds. But maybe in case of smearing it has no effect.