URL:
https://github.com/SSSD/sssd/pull/107
Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler
fidencio commented:
"""
Pavel,
On Tue, Dec 13, 2016 at 11:20 AM, Pavel Březina <notifications(a)github.com>
wrote:
There are two scenarios:
1. timeshift during system boot -- it is very common to be several
hours
2. timeshift due to an ntp update when booted up -- usually only few
seconds, not a big deal
The problem with tevent timer is that if we shift backwards the timer
remains too far in the future. This applies to all timers, not only for the
watchdog. Forward shift is not a problem, it just executes the timers
immediately. Resetting the watchdog helps in a way that sssd is not killed,
we don't have any capability to reschedule all timed event and we actually
can not tell that sssd will be functioning properly (dyndns, sudo refresh,
enumeration, domain refresh, even idle timer on socket activation)... all
those operations that depends on time() would become unreliable.
I think the best thing to do would be restart the process (although the
question is how would this affect the boot up) and patch tevent to deal
with timeshift either by using monotonic clock or by detecting them and
altering timers accordingly.
In the latest version of patch I've just called _exit(1) when the timeshift
is detected.
About patching tevent, I've seen some old discussions happening and it
doesn't seem a trivial thing to do. Would the patch, as it is right now, be
acceptable and then a work on tevent could be done later (yes, I'd add it
to my queue and do it as soon as we have an agreement on doing this)?
"""
See the full comment at
https://github.com/SSSD/sssd/pull/107#issuecomment-266702069