Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 1 Jun 2015 23:19:53 -0700 | Subject | Re: [RFC][PATCH 0/4] Fixes for leapsecond expiring early ABS_TIME CLOCK_REALTIME timers | From | John Stultz <> |
| |
On Mon, Jun 1, 2015 at 3:29 PM, Daniel Bristot de Oliveira <bristot@redhat.com> wrote: > > > Il 01/06/2015 18:42, Prarit Bhargava ha scritto: >> Daniel, did you disable chronyd/ntpd? I've seen both failures if I leave >> chronyd running. >> >> P. > > Prarit, John, that is it, chronyd was running.
I reproduced this with chronyd running in the background, and while its unlikely to be an edge case anyone would hit in normal usage, I'm looking at how to ensure the adjtimex state is handled better.
It basically comes down to chrony modifying the timex.time_status removing the STA_INS flag, which doesn't get processed to change the time_state from TIME_INS -> TIME_OK until the next second_overflow(). Since STA_INS flag is not present, the leap-second is not applied at the second edge, and we see the strange TIME_INS state run through what should be the leapsecond.
Mostly this is an issue with the test not printing the time_status details, so the output looks especially confusing. Richard's point about modifying the time_state immediately when the STA_INS flag is dropped by adjtimex, rather then waiting for the next second_overflow call would likely make this case more sensible as well.
But again, this is a problematic edge case of two adjtimex controllers running at the same time, which isn't really valid to begin with, so I'm less worried about trying to get this issue fixed and into -stable, and am fine with improving it via a test output change or via a separate patch to change the time_state state machine.
thanks -john
| ![\](/images/icornerr.gif) |