Comment 1 for bug 1424966

Confirmed, this is related to the TFD_TIMER_CANCEL_ON_SET change. Looks like timerfd_settime() is failing and setting errno to ECANCELED. This isn't listed as a possible error in the manpage but now that we're hitting ECANCELED a web search turns up the condition pretty quickly.

The ability to return ECANCELED was added was added for this use case:

<http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=99ee5315dac6211e972fa3f23bcc9a0343ff58c4>

> Some applications must be aware of clock realtime being set
> backward. A simple example is a clock applet which arms a timer for
> the next minute display. If clock realtime is set backward then the
> applet displays a stale time for the amount of time which the clock
> was set backwards. Due to that applications poll the time because we
> don't have an interface.
>
> Extend the timerfd interface by adding a flag which puts the timer
> onto a different internal realtime clock. All timers on this clock are
> expired whenever the clock was set.
>
> The timerfd core records the monotonic offset when the timer is
> created. When the timer is armed, then the current offset is compared
> to the previous recorded offset. When it has changed, then
> timerfd_settime returns -ECANCELED. When a timer is read the offset is
> compared and if it changed -ECANCELED returned to user space. Periodic
> timers are not rearmed in the cancelation case.
> http://www.spinics.net/lists/linux-tip-commits/msg11814.html

Likely solution: in indicator-datetime/src/clock-live.cpp, move the timerfd_create() call from LiveClock::Impl::Impl() to LiveClock::Impl::reset_timer(), also adding a test to close() the previous timer if it's not -1.

I will be able to start on this in ~10 hours when my jury duty is done for the day. If this bug is deemed as supercritical, please feel free to reclaim the ticket and fix it before then.