Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler
On Tue, Dec 13, 2016 at 02:44:44AM -0800, Simo Sorce wrote:
On Tue, 2016-12-13 at 02:25 -0800, fidencio wrote:
> On Tue, Dec 13, 2016 at 11:20 AM, Pavel Březina <notifications(a)github.com>
> > 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)?
This is really a blunt tool (calling exit()), but until tevent can be
fixed the only other option would be to use some wrapper to keep track
of all existing timed events and cancel and restart them all if the
clock changes abruptly.
that's why I suggested signaling self to a tevent-driven signal handler
from where we can just set up the timer anew.
If there is any other way to 'break out' of the POSIX signal handler
into somewhere where we can call tevent/talloc (or in general unsafe
calls) I'm all ears.
The easiest option is to teach tevent about the existence of
clocks and allow to set a default clock type to use as well as overrides
for specific timers that want to fire on the actual time not just X
seconds in the future.
Simo Sorce * Red Hat, Inc * New York
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-266745077